RFC: Create Editorconfig File as Part of Cargo Project

Rendered

👉 Rendered

First of all, thank you for the contribution.
However, as discussed in the pre-RFC thread, I don't think this is a good idea to do by default. Having a cargo option to enable this, or putting it in a cargo template, or similar mechanisms all seem fine.
Among other things:

Many editors already have this as the default configuration for Rust; this configuration would be redundant in that case.
Adding such default configuration to any editors that don't already have it would address this issue for every project, without needing these files. At that point, the editorconfig files would be entirely redundant, and would have spread through the ecosystem.
Of the editors mentioned that have editorconfig support, while "several" support it without plugins, many just have it as a plugin that requires installation and enabling, so counting that as "support" doesn't seem appropriate. What subset of editors would this "work out of the box" for?
This adds an extra file in the repository, and the first one not required to build the project. (Hence the suggestion above to make this optional and disabled by default.)
For projects that use rustfmt / cargo fmt, this would be redundant, and would add an extra place to change settings separate from rustfmt.toml.
Ironically, this might well make it more likely that people would diverge from the standard Rust style, since it has the defaults visible right there for editing.
The user may already have a prevailing style configured as part of a higher-level project, and this would override that.
While we can hope that most projects follow the prevailing Rust style, attempting to enforce that style via editor configuration seems likely to generate at least some surprise and pushback. Imagine, for instance, a large existing project with a standard style, who intend to use that same style for Rust code. On balance, I don't want anyone's first exposure to Rust to be tainted by a negative impression of "oh, this language is opinionated about formatting".

Separately from that, an issue with the proposed defaults:

This should not apply to *, only to *.rs and *.toml.

First of all, thank you for your feedback :)

Many editors already have this as the default configuration for Rust; this configuration would be redundant in that case.

I tried vim, atom and notepad++, none of them were consistent here without editorconfig.

Adding such default configuration to any editors that don't already have it would address this issue for every project, without needing these files. At that point, the editorconfig files would be entirely redundant, and would have spread through the ecosystem.

As said in the RFC, that would be great, yet that is far away, let's not ignore a realistic solution in favor of some hypothetical future.

Of the editors mentioned that have editorconfig support, while "several" support it without plugins, many just have it as a plugin that requires installation and enabling, so counting that as "support" doesn't seem appropriate. What subset of editors would this "work out of the box" for?

See the incomplete list of no plugin required here https://editorconfig.org/:

GitHub
Gogs
IntelliJIdea
KtextEditor
Komodo
Kakoune
VisualStudio
PyCharm
ReSharper
Rider
RubyMine
SourceLair
TortoiseGit
WebStorm
Kate

Normalized by usage, using this survey editorconfig is supported by 98.4% of development   environments and rustfmt by 37.8% for web developers and 98.7% vs 28.3% for desktop developers respectively. That is a very big difference!
Avoiding a solution for 2/3 of the community only because there might be support for rustfmt at some point in the future seems like a poor decision.

This adds an extra file in the repository, and the first one not required to build the project. (Hence the suggestion above to make this optional and disabled by default.)

Vcs git is required for building?

For projects that use rustfmt / cargo fmt, this would be redundant, and would add an extra place to change settings separate from rustfmt.toml.

Indeed that's unfortunate, one option would be to add warnings in rustfmt about this. Parsing editorconfig files should be relatively simple, plus there are already crates for this in the wild.

Ironically, this might well make it more likely that people would diverge from the standard Rust style, since it has the defaults visible right there for editing.

This is about psychology, if you have someone likely to change the defaults, I speculate they will also not be the people that use rustfmt with default settings, and at least with editorconfig they documented their change, and when I open a pull request for their project. I can avoid some needless friction.

The user may already have a prevailing style configured as part of a higher-level project, and this would override that.

All editors with editorconfig, be it default or with plugin, show an icon that  editorconfig is active for the file. If the style conflicts with their previous style, they have the option to change editorconfig to match their previous style or remove the file. Both are very easy and shouldn't take much time. As always for defaults it is about finding the most common use case and expressing them without cannibalizing corner cases.

On balance, I don't want anyone's first exposure to Rust to be tainted by a negative impression of "oh, this language is opinionated about formatting". The high cost of that, versus the minor annoyance of some projects diverging from the standard Rust style, does not favor a change like this.

That argument seems very inconsistent, the rust book mentions the opinionated rust style in the first chapter at 'Hello World':

There are four important details to notice here. First, Rust style is to indent with four spaces, not a tab.

Either we as a community express opinionated formatting, or we don't. Saying we do in the rust book which is and should be the entry point for most people, and then shying away from expressing this in a configuration file seems off.

This should not apply to *, only to *.rs and *.toml.

Editorconfig essentially only applies to files that are being edited, which usually means source code. Still, you are right, indent size and style and trim trailing whitspace can cause issues in other files. For example in markdown trailing whitespace has an impact on formatting.
How about:
# https://editorconfig.org
root = true

[*]
charset = utf-8
end_of_line = lf

[*.{rs,toml}]
indent_size = 4
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true

This way a uncontroversial subset is applied to everything, and the opinionated things only apply for rust files. Of course there are cases where the global rules could be problematic, however they seem very corner case, and as said above in those cases, the user can edit or remove this file.

On Mon, Sep 24, 2018 at 05:39:04PM +0000, Lukas Bergdoll wrote:

Adding such default configuration to any editors that don't already have it would address this issue for every project, without needing these files. At that point, the editorconfig files would be entirely redundant, and would have spread through the ecosystem.

As said in the RFC, that would be great, yet that is far away, let's not ignore a realistic solution in favor of some hypothetical future.

It's not hypothetical; getting editors to set appropriate defaults is
quite feasible.

Normalized by usage, using this survey editorconfig is supported by 98.4% of development   environments and rustfmt by 37.8% for web developers and 98.7% vs 28.3% for desktop developers respectively. That is a very big difference!

I'm having trouble interpreting the results from that survey, given that
the percentages don't add up to 100%; I'd assume that's a "check all the
environments you use" poll? I don't think you can extrapolate or add
with such percentages.

Avoiding a solution for 2/3 of the community only because there might be support for rustfmt at some point in the future seems like a poor decision.

I'm not talking about "editors might support rustfmt", I'm talking about
that projects and people can use rustfmt or cargo fmt themselves.

This adds an extra file in the repository, and the first one not required to build the project. (Hence the suggestion above to make this optional and disabled by default.)

Vcs git is required for building?

I'm not sure what you mean by this.

Ironically, this might well make it more likely that people would diverge from the standard Rust style, since it has the defaults visible right there for editing.

This is about psychology, if you have someone likely to change the defaults, I speculate they will also not be the people that use rustfmt with default settings, and at least with editorconfig they documented their change, and when I open a pull request for their project. I can avoid some needless friction.

Not what I mean. Built-in defaults don't call attention to themselves; a
.editorconfig file draws attention.

The user may already have a prevailing style configured as part of a higher-level project, and this would override that.

All editors with editorconfig, be it default or with plugin, show an icon that  editorconfig is active for the file.

I can't speak for other editors, but vim does not, AFAICT.

If the style conflicts with their previous style, they have the option to change editorconfig to match their previous style or remove the file. Both are very easy and shouldn't take much time. As always for defaults it is about finding the most common use case and expressing them without cannibalizing corner cases.

I think you might be underestimating the knee-jerk reactions people have
over indentation style and opinionated tools. :)
Consider projects trying to incrementally replace C with Rust, for instance.
Consider the difference between "here's this tool called rustfmt" and
"here, let me automatically format your code for you without asking".
I genuinely appreciate the goal of trying to provide defaults that work
well for people. I feel that creating a new file in every new project is
too much.
This feels like something best addressed via cargo templates, so that
you (or an organization) can easily choose to have this happen for all
new projects you create.

On balance, I don't want anyone's first exposure to Rust to be tainted by a negative impression of "oh, this language is opinionated about formatting". The high cost of that, versus the minor annoyance of some projects diverging from the standard Rust style, does not favor a change like this.

That argument seems very inconsistent, the rust book mentions the opinionated rust style in the first chapter at 'Hello World':

There's a difference between having a default style and emitting files
that configure a user's editor.

This should not apply to *, only to *.rs and *.toml.

Editorconfig essentially only applies to files that are being edited, which usually means source code. Still, you are right, indent size and style and trim trailing whitspace can cause issues in other files.

Also an issue for non-Rust source files, for instance.

How about:
# https://editorconfig.org
root = true

[*]
charset = utf-8

Not something you can safely assume for all projects (sadly).

end_of_line = lf

Not the correct assumption for all platforms, and IIRC not consistent
with existing behavior.

trim_trailing_whitespace = true

This is a problem. Highlighting trailing whitespace so people avoid
puting it in is a good idea. Silently deleting it is a problem, because
that can generate diff noise in unrelated commits.

We discussed this in the @rust-lang/cargo meeting today.
We were quite receptive to the motivation and intention of this proposal, but we'd like to keep cargo new only creating the minimal files needed for a new Rust project. Anything beyond that should be the domain of a project template.
(For the record, we also explicitly discussed that the default of --git doesn't necessarily fit that policy. Nonetheless, that's the existing behavior and widespread expectation.)
@rfcbot fcp close

I'm no longer on the cargo team; how do I get off the rfcbot list? I've manually removed myself from the ticky boxes list.

@joshtriplett:

First of all, thank you for the contribution.
However, as discussed in the pre-RFC thread, I don't think this is a good idea to do by default. Having a cargo option to enable this, or putting it in a cargo template, or similar mechanisms all seem fine.

Agree, I do not think we should have Cargo options for each and every little project scaffold property. Even Cargo’s existing VCS option is questionable. We should have a system for templates, which can be as rich or bare-bones as one may imagine. Rust programmers can create a repo of popular templates and Cargo can help choosing one when generating a new package directory.

Among other things:
* Many editors already have this as the default configuration for Rust; this configuration would be redundant in that case.

No, since it specifies the desired behavior explicitly and in-tree rather than relying on editors used by people working with Cargo package.

* Adding such default configuration to any editors that don't already have it would address this issue for _every_ project, without needing these files. At that point, the editorconfig files would be entirely redundant, and would have spread through the ecosystem.

That is a hypothetical, I do not think this is realistic unless evidence is given otherwise. Adding EditorConfig is not just to configure text editors, it can also be used as e.g. a VCS hook that checks the validity of files under VCS.

* Of the editors mentioned that have editorconfig support, while "several" support it without plugins, many just have it as a plugin that requires installation and enabling, so counting that as "support" doesn't seem appropriate. What subset of editors would this "work out of the box" for?

This seems like a tangential issue. Whether it presently requires a little vs. no effort to use EditorConfig  depending on the editor used is not significant IMO.

* This adds an extra file in the repository, and the first one not _required_ to build the project. (Hence the suggestion above to make this optional and disabled by default.)

How is that bad? Seems very far fetched. There are countless needless scripts and tidbits in most Git repos on GitHub.

* For projects that use `rustfmt` / `cargo fmt`, this would be redundant, and would add an extra place to change settings separate from `rustfmt.toml`.

Only insofar the setting overlap. IMO, they only do for indentation. A discrepancy between rustfmt config and EditorConfig is not a serious problem. The maintainers and ultimately editors/IDEs decides how to handle precedence or how to simple avoid the slight overlap possible.

* Ironically, this might well make it _more_ likely that people would diverge from the standard Rust style, since it has the defaults visible right there for editing.

The EditorConfig file can simply specify text encoding an nothing regarding code style. You’re forgetting about a very important application of EditorConfig files in software development. It’s not just source code files that are being put in source code bases, also text files/documents and structured config files. And this is true for Rust-based packages as well (in my company). There is no standard, cross-platform and cross-tooling method to prescribe let alone enforce the text encoding standard in such code bases, but EditorConfig.

* The user may _already_ have a prevailing style configured as part of a higher-level project, and this would override that.

Only if the EditorConfig file is generated and then kept. That means there are two moment where this situation can be prevented. E.g. generating it can be made non-default.

* While we can hope that most projects follow the prevailing Rust style, attempting to _enforce_ that style via editor configuration seems likely to generate at least some surprise and pushback. Imagine, for instance, a large existing project with a standard style, who intend to use that same style for Rust code. On balance, I don't want _anyone's_ first exposure to Rust to be tainted by a negative impression of "oh, this language is opinionated about formatting". The high cost of that, versus the minor annoyance of some projects diverging from the standard Rust style, does not favor a change like this.

I think you’re making too much of the prescriptions for style in EditorConfig files. The

@joshtriplett: Seeing you arguing in this thread makes me want to call out: do you have effective discussions about this by focusing in the general argument rather than side-issues and subjective positions, and do you feel you’re prioritizing spending time for the Cargo team well enough? This comment is meant as a constructive observation from outside from someone concerned about the future of Cargo.

[Moderation note: One comment hidden. General questions about how teams conduct their business should be directed to the team as a whole, and asked in some other forum.  Comments on GitHub threads should be focused on specific issues or PRs.  Also, if you have concerns, please try to state them directly and not in the form of leading questions or insinuations.]

Copied from rust-lang/cargo#3506:

Imo, the arguments made in rust-lang/rfcs#2549 also apply here, cargo should remain lightweight and only do build system and dependency management related things. Anything extra, like README, Editorconfig, CONTRIBUTING, etc. should be an ergonomic opt in with cargo templates. A popular one could be an OSS template, that has the 3 aforementioned files plus LICENSE.

If we start making exceptions for things like README, where do we draw the line? Also the cargo template story might be less clear, teaching that for anything that is not related to building the software like README files you can use cargo templates, is simple. Unfortunately there are already exceptions to this, like vcs, let's not make the situation worse.

@Centril @joshtriplett given that me, the author of this RFC no longer believes in it, does it make sense to keep it open, or should we close it?

@Voultapher its going through our process for closing by the team, just waiting on one more cargo team member to check their boxes, then it will sit in final comment period until its closed, unless something surprising happens during FCP. As the PR opener you're free to close it immediately if you want, of course.

@mbrubeck:

Also, if you have concers, please try to state them directly and not in the form of leading questions or insinuations.
You are violating your own rule by insinuating I do not state my concern ‘directly’. I’m entitled to have my own opinion about what I see going on here and I stated them directly enough. Do not refer people to ‘some other forum’. If you have wishes or policies, be explicit in what you want. Is that direct enough?

@sanmai-NL

Note that the main value of my comment is pointing out how we’re having a needless discussion full of subjective opinion and irrelevant considerations. I see that you continue it now. That further supports my ‘hidden’ post.

We should have a system for templates, which can be as rich or bare-bones as one may imagine. Rust programmers can create a repo of popular templates and Cargo can help choosing one when generating a new package directory.

Sounds like we're in agreement on that, then.

Whether it presently requires a little vs. no effort to use EditorConfig depending on the text editor used is not significant IMO.

It's relevant to the desirability of supporting editorconfig by default rather than as a non-default item supported in templates.

That may be so, but whether to include it by default is irrelevant if the feature is off the table in the first place.

How is that bad? Seems very far fetched. There are countless needless scripts and tidbits in most Git repos on GitHub.

Not in the ones I've worked with. More importantly, though, those "scripts and tidbits" are normally put in place by the project developers. I'd like to avoid giving the impression that Cargo creates piles of files people don't know about.

Check out https://github.com/rust-lang/rust again then. x.py, various CI configuration files, mailmap, etc.

Something worth noting: Cargo's creation of a .git repository is unlikely to be someone's first introduction to git. Cargo's creation of a .editorconfig file would likely be many people's first introduction to editorconfig.

If you say so. I do not agree Cargo should be Git-centric at all and I do not expect programmers to expect a Git repo by default. But again, this discussion is irrelevant.

The EditorConfig file can simply specify text encoding an nothing regarding code style.

I don't think that's of value to create by default; there's already a widespread default there, namely UTF-8. Also, .gitattributes files seem of more relevance there.

False, not on Microsoft Windows. .gitattributes is for Git, again, why assume people use Git?

E.g. generating it can be made non-default.

That seems fine; by all means let's have template components that include it.

I think you’re making too much of the prescriptions for style in EditorConfig files. There are none for Rust, just indentation (optionally).

Indentation is precisely what I meant.

Making too much of just that is what I meant then.

Moderation note: @sanmai-NL If you have concerns about our moderation practices, then please email the moderation team. Our email address is<EMAIL_ADDRESS>
Thanks for the pointer. Please put these rules in e.g. a code of conduct file in the repo. It’s not a good experience to have some person hide a post for being too critical, and then later to justify it saying I should have e-mailed about it. Just sharing a concern about one person in one instance doesn’t warrant a formal ‘complaint’ IMO, so what you propose here does not feel to me like a good process at all.


Analysis Takeaways

Here is a collated list (so far) or what we want to get out of further runs of the pipeline experiment for future analysis:

OCR full output: so we can swap out models and then re-run the pipeline from the translator step.
Softmax: the 'most naive' first guess approach, simple to extract and maybe useful?

Further additions found in comments below. Todos:

[ ] Decide on when this is a complete list of what we want.
[ ] Implement and run further experiments.

Initial Language for OOD : Italian/Spanish


FATAL: was not able to gather stats on bamfile

Dear WHAM´s team:
I am trying to run WHAM for 7 bam files, each one corresponds to one sample. I would like to do an association test between one of the samples and the other six. Then, I am running:
$ WHAM-BAM -f ref.fa -m 2 -q 15 -p 10 -x 10 -t 1.sort.rmdup.bam -b 2.sort.rmdup.bam,3.sort.rmdup.bam,4.sort.rmdup.bam,5.sort.rmdup.bam,6.sort.rmdup.bam,7.sort.rmdup.bam > 1_vs_all.vcf
But I am getting this error:
INFO: WHAM-BAM will using the following fasta: ref.fa
INFO: WHAM-BAM requires : 2 soft-clips to score breakpoint
INFO: WHAM-BAM skip soft-clips with average base quality below: 15
INFO: WHAM-BAM skip soft-clips with mapping quaity below: 10
INFO: OpenMP will roughly use 10 threads
INFO: target bams:
1.sort.rmdup.bam
INFO: background bams:
2.sort.rmdup.bam
3.sort.rmdup.bam
4.sort.rmdup.bam
5.sort.rmdup.bam
6.sort.rmdup.bam
7.sort.rmdup.bam
INFO: gathering stats for each bam file.
FATAL: was not able to gather stats on bamfile: 1.sort.rmdup.bam
All the bam files were generated using BWA-MEM, and processed with samtools Version: 0.1.19. Here the parameters:
$ bwa mem -R '@RG\tID:1\tSM:1' -M -t 18 ref.fa 1_R1.PF.fastq.gz 1_R2.PF.fastq.gz | samtools view -S -b - > 1.bam
$ samtools sort 1.bam 1.sort.bam
$ samtools rmdup 1.sort.bam.bam 1.sort.rmdup.bam
Any idea what is going on? Or at least something different to try?
Thanks in advance,
Gabriel

Gabriel,
Thank you for reporting this error.  All of your commands look correct.  The subroutine that is throwing the error tries to sample reads from the first 20 sequences in the header.  How many @SQ tags are in your headers?  Are there reads for all @SQs in the header?
I can resolve this bug today.

Hello Zev,
Thanks for you reply. Actually I have 654 @SQ tags in the headers. Since the reference genome is an "uncompleted" assembly (654 contigs) and some contigs are very small (2000bp) and full of repetitive sequences, It is possible that some of them do not contain any mapped reads.
Thanks for trying to fix it!
Gabriel

option 1 - the fastest
change the following :
unsigned int max = 20;    to  unsigned int max = 500;
https://github.com/jewmanchue/wham/blob/master/src/bin/multi-wham-testing.cpp#L627
and then run make.
option 2 - hopefully end of day
I'm going to add a command line option to change the number of seqids sampled.
Thanks again.
--Zev

Great! I tried with "the fastest" and WHAM is running now!
Thank you very much for such a speedy solution!
Gabriel

Great.  If you're wondering the number was set to 20 for the human folks.... to avoid sampling bait sequences.
I'm leaving this open until I provide a command line option.
--Zev

Hi Zev,
I am getting the same error with one of my bam files.
$ ~/bin/WHAM-BAM -f ../human_g1k_v37.fasta -p 15 -q 30 -m 5 -x 24 -t 150924_13-11719_Merged.bam > 150924_13-11719
INFO: WHAM-BAM will using the following fasta: ../human_g1k_v37.fasta
INFO: WHAM-BAM skip soft-clips with mapping quaity below: 15
INFO: WHAM-BAM skip soft-clips with average base quality below: 30
INFO: WHAM-BAM requires : 5 soft-clips to score breakpoint
INFO: OpenMP will roughly use 24 threads
INFO: target bams:
150924_13-11719_Merged.bam
INFO: gathering stats for each bam file.
FATAL: was not able to gather stats on bamfile: 150924_13-11719_Merged.bam
I tried changing the unsigned int max = 20; to unsigned int max = 500; and then run make and I get this error:
src/bin/mergeIndv.cpp:350: warning: comparison between signed and unsigned integer expressions
and it exits out and when I try running it again, its till throws me the same error.
Do you know what's going on here?
Thanks for the help.
Ashini.

Wham is trying to randomly samples windows.  It is assuming that each SQ in the header is fully represented in the bam file. The line of code that is causing you trouble is:
https://github.com/zeeev/wham/blob/master/src/bin/multi-wham-testing.cpp#L622
If you get rid of that block it sample until it gets enough reads.
I'm leaving this open as a bug.
--Zev

Thanks Zev. thanks a ton. This fixed it.
Thanks,
Ashini

Caution for exome data:
If the breakpoint isn't in the capture region, wham will not call it.

Sure. I got it.
Thanks.

I guess here might be a proper thread that I bring my question. I am trying to use WHAM for my WGS data (~30X) and wondering the setting for bwa mem. I have used the bwa command:
'bwa mem fastq.R1 fastqR2'
but seems it does not give me reads with XA tags, when I checked them using samtools view.
Considering commands above, should I use '-M' option for mark shorter split hits as secondary? Is this for XA and/or SA tags? Please correct me if I am wrong or there's recommended command line for bwa mem
Cheers,
Joon

@sehrrot What version of bwa-mem are you using?
Setting the -M flag is fine, not setting -M is fine too.  I think most other tools want -M.

Hi Zev,
I am trying to run WHAM for some single end data. But its been more than 10 hours and it still says "INFO: gathering stats for each bam file."
I have already removed this https://github.com/zeeev/wham/blob/master/src/bin/multi-wham-testing.cpp#L622
so it does not throw out error and is still running. Moreover, there are only 84 @SQ tags in the header file and its a pretty small BAM file with about ~ 71000 reads.
Do you think it might be coz its single end data. Please let me know.
Thanks,
Ashini


Find a way to shrink images size

Is there anything more to clean after packages install?
- Switch to alpine based images?

Debian official images now propose "slim" images, in which documentation is removed.
These images should be used, and documentation removed the same way after package installation.


Fixes

Add missing output product in digi and reco.  Fix NoField.  Add and fix options in gen_Reco.sh

Hi @brownd1978,
You have proposed changes to files in these packages:

Scripts
JobConfig

which require these tests: build.
@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.
:hourglass: The following tests have been triggered for 88e90da74fe844a11b14be5db9d7f822c8069a5e: build  (Build queue is empty)
About FNALbuild. Code review on Mu2e/Offline.

:umbrella: The build tests failed for 88e90da74fe844a11b14be5db9d7f822c8069a5e.

Test
Result
Details

test with
:white_check_mark:
Command did not list any other PRs to include

merge
:white_check_mark:
Merged 88e90da74fe844a11b14be5db9d7f822c8069a5e at 63f392b2cd8cf97c0ba86bb6e0872bd965050f6c

build (prof)
:white_check_mark:
Log file. Build time: 14 min 25 sec

ceSimReco
:x:
Log file. Return Code 9.

g4test_03MT
:white_check_mark:
Log file.

transportOnly
:white_check_mark:
Log file.

POT
:white_check_mark:
Log file.

g4study
:white_check_mark:
Log file.

cosmicSimReco
:white_check_mark:
Log file.

cosmicOffSpill
:white_check_mark:
Log file.

ceSteps
:white_check_mark:
Log file.

ceDigi
:white_check_mark:
Log file.

muDauSteps
:white_check_mark:
Log file.

ceMix
:white_check_mark:
Log file.

rootOverlaps
:white_check_mark:
Log file.

g4surfaceCheck
:white_check_mark:
Log file.

FIXME, TODO
:white_check_mark:
TODO (0) FIXME (0) in 0 files

clang-tidy
:white_check_mark:
0 errors 0 warnings

N.B. These results were obtained from a build of this Pull Request at 88e90da74fe844a11b14be5db9d7f822c8069a5e after being merged into the base branch at 63f392b2cd8cf97c0ba86bb6e0872bd965050f6c.
For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

@FNALbuild run build test with Mu2e/Offline#962

:hourglass: The following tests have been triggered for 88e90da74fe844a11b14be5db9d7f822c8069a5e: build  (Build queue is empty)

:sunny: The build tests passed at 88e90da74fe844a11b14be5db9d7f822c8069a5e.

Test
Result
Details

test with
:white_check_mark:
Included Mu2e/Offline#962 @ 8dca54035bd1b5b542d2e867b8d040fba0ab4480 by merge

merge
:white_check_mark:
Merged 88e90da74fe844a11b14be5db9d7f822c8069a5e at 63f392b2cd8cf97c0ba86bb6e0872bd965050f6c

build (prof)
:white_check_mark:
Log file. Build time: 13 min 14 sec

ceSimReco
:white_check_mark:
Log file.

g4test_03MT
:white_check_mark:
Log file.

transportOnly
:white_check_mark:
Log file.

POT
:white_check_mark:
Log file.

g4study
:white_check_mark:
Log file.

cosmicSimReco
:white_check_mark:
Log file.

cosmicOffSpill
:white_check_mark:
Log file.

ceSteps
:white_check_mark:
Log file.

ceDigi
:white_check_mark:
Log file.

muDauSteps
:white_check_mark:
Log file.

ceMix
:white_check_mark:
Log file.

rootOverlaps
:white_check_mark:
Log file.

g4surfaceCheck
:white_check_mark:
Log file.

FIXME, TODO
:white_check_mark:
TODO (0) FIXME (0) in 0 files

clang-tidy
:white_check_mark:
0 errors 0 warnings

N.B. These results were obtained from a build of this Pull Request at 88e90da74fe844a11b14be5db9d7f822c8069a5e after being merged into the base branch at 63f392b2cd8cf97c0ba86bb6e0872bd965050f6c.
For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.


There's nothing here

What is this? There's nothing here by a skeleton.

And yet, the NuGet package actually links to an actual package. Weird stuff!


how to send the trace span to istio / kubernetes?

I am submitting metrics using:
   <dependency>
        <groupId>io.opentracing.contrib</groupId>
        <artifactId>opentracing-spring-jaeger-cloud-starter</artifactId>
        <version>3.3.1</version>
    </dependency>

We're not maintaining that project. Please file an issue in their repo.


Getting ready for mainnet

This PR prepares the backend for a mainnet demo. As far as I can tell we only need the updated addresses (URLs can be configured in kubernetes) and provide a hacky way of ensuring we use enough gas. Given that ethcontracts ships with web3 gas estimation, I thought the easiest way is to just hardcode a factor for now.
Test Plan

Why mainnet for the demo? I feel we're wasting money on real transactions and making things more complicated with gas prices.
We also aren't ready to run the solver on mainnet unsupervised because we could end up wasting gas on failing transactions over and over again.

The demo on rinkeby is quite clumsy (the prices are way off and there is basically only one pair DAI/WETH which can be used to demo a trade). Also the tooling around (e.g. etherscan) doesn't show as nicely what is happening and a demo with real value is just more "impressive" in general.
I agree that we will be "waisting" real money on gas, but I'm not worried regarding failing txs (in my local tests so far we never executed a failing tx). Since we are not enforcing a fee I would think the biggest risk is someone doing a lot of miniscule trades (but I also think it would have to be someone from the team as we didn't share any links publicly yet).
Maybe we can test it and then only turn it on for the demo (outside of it we either don't run the solver or use a very small gas fraction).

I guess regardless of the decision on which network to do the demo, it's ok to merge this (we can control if we want to use it in kubernetes).


Failing test_image_example

There is another test failing.
=========================================================== test session starts ============================================================
platform darwin -- Python 2.7.10 -- pytest-2.5.1

Running tests with Astropy version 1.1.dev13304.
Running tests in astroplan /Users/bsipocz/munka/devel/astroplan/docs.

        The two given filenames may point to files which are convertible to
        PNG via the `.converter` dictionary. The underlying RMS is calculated
        with the `.calculate_rms` function.

        Parameters
        ----------
        expected : str
            The filename of the expected image.
        actual :str
            The filename of the actual image.
        tol : float
            The tolerance (a color value difference, where 255 is the
            maximal difference).  The test fails if the average pixel
            difference is greater than this value.
        in_decorator : bool
            If called from image_comparison decorator, this should be
            True. (default=False)

        Example
        -------
        img1 = "./baseline/plot.png"
        img2 = "./output/plot.png"
        compare_images( img1, img2, 0.001 ):

        """
        if not os.path.exists(actual):
            msg = "Output image %s does not exist." % actual
            raise Exception(msg)

        if os.stat(actual).st_size == 0:
            msg = "Output image file %s is empty."
        num_values = np.prod(expectedImage.shape)
>       abs_diff_image = abs(expectedImage - actualImage)
E       ValueError: operands could not be broadcast together with shapes (600,800,3) (660,880,3)

/sw/lib/python2.7/site-packages/matplotlib/testing/compare.py:246: ValueError

This is the test_image_example I added today that uses pytest-mpl.
For some reason the image that was generated on my computer and travis-ci has shape 800 x 600, and @bsipocz, on your computer 880 x 660.
@bsipocz @astrofrog – Any idea what needs to be changed to get reproducible image size on all computers? What's the recommended pattern to do this?

Differences can be due to differing matplotlibrc files. Can you both check whether you have an active matplotlibrc file?
Ideally I think we should save a JSON dictionary of the RC params with each figure to ensure reproducibility, and it's on my to-do list for pytest-mpl.

Good point, indeed I have  u'figure.figsize': [8.8, 6.6], set in rcParams.

So what I have is with default setting for matplotlib 1.4.
So those tests would break when matplotlib 2.0 comes out soon with a new style.
@astrofrog – Defining our own plotting style for astroplan should be enough to keep these tests future-proof? (We plan to do this soon: #74) Or what's the recommended pattern to set this up in a robust way?

Moving this to 0.2 ... it shouldn't block the 0.1 release which is long overdue.

Pinging @astrofrog again to see if he has a solution to this issue.

@bmorris3 - I have a solution, in my head, I just haven't had a chance to implement it yet ;)
Though actually for now, you can emulate this solution by resetting the rc parameters to the default at the start of the test:
plt.rcParams.clear()
plt.rcParams.update(plt.rcParamsDefault)

Marking Issue as stale and closing. Please re-open if still affected by this Issue.


feat: increase goldpinger timeouts and add goldpinger troubleshoot spec

What this PR does / why we need it:

Increases goldpinger addon timeouts. In slowish networks, pings tend to fail unnecessarily. The default ping timeout is 300ms.
Add a support bundle spec whenever goldpinger addon is added to a kurl spec.

Which issue(s) this PR fixes:

Fixes #sc-91987
Special notes for your reviewer:

Steps to reproduce

Create a kURL cluster
Run support-bundle --load-cluster-specs and notice goldpinger analysis in the results. This bit is dependant on https://github.com/replicatedhq/troubleshoot/pull/1398 changes being released

Does this PR introduce a user-facing change?

NONE

Does this PR require documentation?

NONE

The latest version appears to work, but the previous ones are failing


added list function and test cases

I think you could directly use list_pets() from the template repo to complete this task.


Start menu shortcuts for individual features.

Description of the new feature / enhancement
Allow individual features to be accessed through the start menu as opposed to opening the PowerToys application first or hitting the hotkey combination to bring it up. This doesn't necessarily make sense for all features, but for features that involve opening a separate window (such as color picker and fancyzones), it definitely makes sense to have a start menu shortcut.
Scenario when this would be used?
If someone wanted to use the global color picker they may find it more convenient to simply open the start menu and activate the color picker from there instead of having to memorize a keyboard combination or open the powertoys application.
Supporting information
No response

/dup #907


Build Tensorflow and libtensorflow from source

Motivation for this change
Restore Tensorflow source build while leaving binary builds . Based on @yorickvP and @timokau work.with some parts taken from both.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

cc @uri-canva for changes regaring Bazel.
Tested both CUDA and non-CUDA builds of the Python library, both source and binary builds. Didn't test libtensorflow, I assume that if Python library works and ldd output is okay libtensorflow is okay too.

Forgot to mention actual previous PRs: #63208 and #63616.

Darwin still uses binary builds for now. I don't have a Darwin machine so I can't test if source build works and fix it if it doesn't - unless someone wants to take on that role!

(For some reason I cannot request a review from @yorickvP on Github)

Updated binary libtensorflow doesn't build for Darwin. Can someone with Darwin knowledge help with it?

Updated binary libtensorflow doesn't build for Darwin. Can someone with Darwin knowledge help with it?

It seems that Google now build on newer macOS versions, I had the same problem with Tensorflow 1.13.1 when building on my own MacBook with Mojave. A newer cctools is needed, see #49371. This PR is probably needed: #61172

This is great! I'm hoping to get a fully static build at some point, but having the same protobuf on tensorflow as the rest of the code should fix our linker errors! :)
You can't request a review from me because I don't have commit rights, I suppose.

As I mentioned in https://github.com/NixOS/nixpkgs/pull/63616, there are still issues with the python2 build. Seems to be a general problem with parallelism on python2, only manifests itself here because its such a big project and basically hopeless to build without a lot of parallelism (used 12 cores).
I already added one patch to python2 (https://github.com/NixOS/nixpkgs/pull/64067), but I still saw the issue (sometimes, its transient) after that. I suspect the second part of the fix in the python ticket is also needed. That was never backported by debian, so I had to do it myself (being not very experienced with C). I've pushed those changes to the branch of the other PR. Its not very polished, which is why I didn't push it before.
I don't have time to work on this or give extensive review right now. But I can answer questions if you have any.

@timokau I saw that one but IIUC this is a general Python problem, not Tensorflow-specific one, so I didn't really look into it. It shouldn't happen during the "big" Tensorflow build because I only build "source" package now and build the wheel separately with our buildPythonProgram. I didn't observe the problem on 8-core (16-thread) machine during ~10 builds too.

Neat, so you only need bazel for the C part and don't need to unnecessarily rebuild everything  for libtensorflow, py2 tensorflow and py3 tensorflow?

Sadly no, you still need to rebuild everything because their C libraries link to different Pythons and I presume use different APIs. Still, in the end you get something that resembles a usual source Python package with setup.py etc. I use this as src for buildPythonPackage so any Python bugs should be isolated there.

Oh, so you mean you just skip the final bdist_wheel as it was done previously? I actually changed that on purpose, so that we can unify the binary and source builds. That way we wouldn't have all the duplication between default.nix and bin.nix.
I don't think the bdist_wheel step alone was responsible for the build failures, but who knows.

The primary reason I switched back to the previous behavior was to ensure fixupPhase runs on unpacked Tensorflow libraries. This ensures RPATH is set up correctly.

Will this work with bazel 0.28.0? https://github.com/NixOS/nixpkgs/pull/64633

My PR had some issues with bazel 0.27, not sure if @abbradar worked around those. But the bazel team has promised no further backwards incompatibilities for the next 3 releases (then they'll break backwards compatibility once more and release 1.0).

But the bazel team has promised no further backwards incompatibilities for the next 3 releases (then they'll break backwards compatibility once more and release 1.0).

Nice news! I didn't test 0.28 though yet, wanted to do it today but sadly I won't have time for one more rebuild.

some issues with bazel 0.27, not sure if @abbradar worked around those

Huh, didn't notice anything. Maybe you remember something specific? I apply patch for 0.27 from upstream and also add a flag to enable backwards compatibility with some behavior.

@abbradar IIRC there were some python2 issues, I think caused by a mix of bazel moving to python toolchains and 27d4ce7ce08613ab124d160ff269c48c86eb3d83.

That was deterministic though, so if py2-tensorflow builds now with current master and this PR it should be fine.

Here's the details of the bazel plans: https://blog.bazel.build/2019/06/06/Bazel-Semantic-Versioning.html
Hopefully it won't be as much of a pain anymore from now on.

@timokau I feel quite stupid right now - I completely forgot to test this with python2.
Stay tuned...

Yeah, forgot that for a while too until I noticed it suddenly wasn't working anymore. Can't wait until we can drop support for python2.

With https://github.com/NixOS/nixpkgs/pull/64900 and a partial revert of https://github.com/NixOS/nixpkgs/pull/53988 Python 2 version builds fine for me too. I'm rebuilding it the third time just to be sure but it was perfectly reproducible without the .pyc patch.

@GrahamcOfBorg build bazel.tests

The changes to bazel look indeed good, all tests pass.

I'm rebuilding it the third time just to be sure but it was perfectly reproducible without the .pyc patch.

I'm a bit confused by this. So you had no issues without the python patch in https://github.com/NixOS/nixpkgs/pull/64900? Why add it then?

Nono, the problem was that I somehow messed up I Python 2 and 3, so I thought that I evaded the bug because Python 3 worked.

So you mean that you're trying to verify that it's perfectly reproducible with the pyc patch?
For what it's worth for verification I used my nix-rebuild script like this:
try=0
while nix-rebuild python2.pkgs.tensorflow >logs/$try.log 2>&1; do
    echo "$try done"
    (( try += 1 ))

And just let that run overnight.

Yup, I'm actually running something similar right now and want to leave it overnight too.

In the message above I meant that without the patch I couldn't build it successfully even once before

Oh, now I understand. For me it wasn't entirely deterministic, which was annoying. That's why I prematurely concluded https://github.com/NixOS/nixpkgs/pull/64067 had fixed the issue.

Now that other parts are here I'll wait till staging goes into master and merge this (so that we don't break Python 2 + Tensorflow).

Why not just retarget this PR to staging and merge now? Then we'll get it automatically on the next staging-next merge.

Well, I usually avoid crowding staging with not-mass-rebuildy PRs to ease bisect in case it's needed (searching for problems among mass rebuild commits can be painful).
On July 17, 2019 2:23:15 PM GMT+03:00, Timo Kaufmann<EMAIL_ADDRESS>wrote:

Why not just retarget this PR to staging and merge now? Then we'll get
it automatically on the next staging-next merge.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/NixOS/nixpkgs/pull/64716#issuecomment-512213020

--
Nikolay.

Fair enough.

I tried to build tensorflow with SSE4.1 support, but unfortunately the build failed. Apparently that has to be specified at configure time now. This is my attempt to get it working:
https://github.com/timokau/nixpkgs/commits/3323284
The patch to buildBazelPackages is necessary since tensorflow won't accept the --config=opt flag for fetching.
Feel free to cherry-pick and/or rebase.

@abbradar in case you haven't noticed yet, the tensorflow build (py2 and py3, but there are different issues for py2 and py3 I think) is currently failing. Unfortunately I don't have access to the necessary compute resources to debug this right now.

Fixed in 71095460b94b6c382afe188d1caa0b7048030b8a. Thanks for the heads up!


Useless functions

Description:
deduct_tax and deduct_tax_new from moneymarket packages (krp-markets) do not perform any kind of tax deduction or operation over the input amount. This functions can be removed.
Code location:
krp-market-contracts/packages/moneymarket/src/querier.rs#L126-L144

An adjustment will done . deduct_tax will be retained. There is no tax on the main network. An assumed value will be set in the test code. Therefore, in order for the test code to correctly simulate different scenarios, deduct_tax will be retained.


[New version] Medic bots cause extreme lag

Ebots using the medic class lag the server greatly. All other classes work well.

new version is desinged to be use waypoints only, now i have switched cbasenpc for high performance navmesh pathfinding redownload ebots and try again.

Thank you!! I will redownlod again this evening and let you know

Ok, update. The navmesh works a lot better. Some bots get stuck on the glass in spawn on ctf_doublecross.

I think the second error (bots stuck walking in circles on capture point) might be caused by this line:
https://github.com/EfeDursun125/TF2-EBOTS/blob/d0b609030b60c5ce30044203abf5628c5ed8200d/NewVersion/include/ebotai/goap/defaultai.inc#L771

The medic bot lag is fixed with the latest update!


Relocate guava in shaded hive-exec

This is causing some conflicts for Iceberg writes with HiveCatalog

R: @chamikaramj

LGTM. Thanks.


bug: Hardware engine detection (Linux) - Tensorrt-llm displays Not installed instead of Incompatible

Cortex version
v93
Describe the Bug
Linux 22
VM: ubuntu app 1 (no GPU)
See screenshot -
cortex engines list should return tensorrt-LLM Incompatible, but it shows Not Installed
Steps to Reproduce
No response
Screenshots / Logs

What is your OS?

[ ] MacOS
[ ] Windows
[X] Linux

What engine are you running?

[X] cortex.llamacpp (default)
[ ] cortex.tensorrt-llm (Nvidia GPUs)
[ ] cortex.onnx (NPUs, DirectML)

Resolved as of v1.0.0


Set fixed/known variance for data points

Instead of a trainable variance for a Gaussian likelihood, be able to set and fix the variance per data point if the data errors are known.

This is now possible with the exact model by passing a variance of shape (data_points,). This is automatically activated when setting the Y_err in mogptk.data.Data or by passing the y_err_col to either LoadCSV or LoadDataFrame.


Zoomout event is not working as expected

I added the code below,
document.addEventListener('zoomout', function(e) {
console.log("zoomout" + e);
});
in order to listen to zoomout event, but when I click on zoom in or zoom out, it never execute the console.log, anyone know how to intercept the zoomout event?

It's emitted on the event bus:
https://github.com/mozilla/pdf.js/blob/f6bc93402ef35675ce61a278e3abe6b93d7fd393/web/app.js#L1306
Therefore, you either have to listen for it on the event bus or configure the event bus to dispatch events to the DOM:
https://github.com/mozilla/pdf.js/blob/f6bc93402ef35675ce61a278e3abe6b93d7fd393/web/pdf_viewer.component.js#L39


SonarCloud for external PRs

@echebbi a well-known limitation of using SonarCloud from GitHub Actions is that secrets are NOT available for external PRs.
This means that we are not able to scan PRs with SonarCloud (unless we merge them, which might be too late, or recreate a clone PR on this very repository with our push admin rights, which is definitely a huge effort).
I saw that other projects simply put the SonarCloud token in clear text in their GitHub Actions workflow... after all, what an attacker would do is only messing up with the SonarCloud results...
shall we try?
I'd feel more comfortable if we analyzed also external PRs :)

I saw that other projects simply put the SonarCloud token in clear text in their GitHub Actions workflow... after all, what an attacker would do is only messing up with the SonarCloud results...

Well, since SonarCloud reports issues on code attackers could get access to the full codebase, couldn't they? That's not an issue for public repos, but it could be a threat for private ones. And since, AFAIK, Sonar tokens provide full access to the account (not repository-based restriction) hence exposing all repositories of the owner.

shall we try?

That being said my SonarCloud only has public repo and I don't plan to add private ones in the near future so, yeah, sure, I think we can give it a try.

OK, let's see first whether I can find an alternative solution (I'm already working on that) and we really can't find another way we'll try with the clear text token

Hey @LorenzoBettini did you find any solution? I believe that having two different PR for a single contribution is highly confusing during reviews. If we don't have any alternative I'm willing to share SonarCloud's token: as I said previously I don't think that's a big deal for me right now since all my repos are public.

I succeeded in analyzing an external PR with SonarCloud (I created a very small project so it was easy to experiment); I've used a mix of pull_request_target (note that's different from pull_request) and a kind of hack (documented) to get the code of the pull request. Unfortunately, such an analysis does not help at all:

it does not annotate the PR anyway
it does not link the issues (and code coverage) to the code (since it comes from an external GitHub repository)

So currently there's no way to do that... creating an additional internal PR is not too much work in the end (and the two PRs seem to stay connected: if I build our PR it also shows the builds on the original external PR; if I merge the original external PR also our PR is considered as merged).
What I did, in general, was to add as a remote Git repository the repository of the contributor; this also allowed me to have the code on my computer (that's how I got to know about the problems on KDE)
Maybe we could go on like that some more time?

and the two PRs seem to stay connected: if I build our PR it also shows the builds on the original external PR; if I merge the original external PR also our PR is considered as merged

That's good to know.

Maybe we could go on like that some more time?

Understood.


Update to latest feathers-hooks-common?

I'm getting 2 deprecated warnings and this module seems to be very much behind...
I could PR if you want? However I might not see all the dependencies etc....
npm WARN deprecated<EMAIL_ADDRESS>Feathers v3 is out and has moved to @feathersjs/errors. See https://docs.feathersjs.com/migrating.html for more information.
npm WARN deprecated<EMAIL_ADDRESS>Feathers v3 is out and this module has been integrated into Feathers core. See https://docs.feathersjs.com/migrating.html for more information.
npm WARN<EMAIL_ADDRESS>No license field.

I would appreciate a PR. I plan to get back to this repo after writing the docs for the graphql adapter, and for the resolver generator for it. So I'm tied up on that for a month.

Done in https://github.com/feathers-plus/authentication-local-management rewrite.


Added logging of port forwarding stdout/stderr

This change modifies the signature of PortForwarding to include an stdout/stderr io.Writer. It also provides a writer that can be built from a logging function
Signed-off-by: Francesco Guardiani<EMAIL_ADDRESS>

/assign @vaikas

/retest

/lgtm
/approve


test/codegen: wrong test cases not detected

The following test case in memcombine.go is wrong, the MOVH is never generated, and still two MOVB remain there. But the codegen test framework does not detect that failure.
func zero_byte_2_idx(b []byte, idx int) {
	// arm64: `MOVH\sZR,\s\(R[0-9]+\)\(R[0-9]+<<1\)`,-`MOVB`
	b[(idx<<1)+0] = 0
	b[(idx<<1)+1] = 0
}

The failure can only be detected in the below form
func zero_byte_2_idx(b []byte, idx0 int) {
	b[(idx0<<1)+0], b[(idx0<<1)+1] = 0, 0 // arm64:`MOVH\sZR,\s\(R[0-9]+\)\(R[0-9]+<<1\)`,-`MOVB`
}

cc @cherrymui @williamweixiao

cc @randall77 @rasky

Can we trim whitespace? I can very easily see myself making that mistake—and am wondering now whether I already have.

Technically, it should be a syntax error, but since parsing is made with a regexp, the regexp simply doesn't match and there's no obvious way to tell a comment line in English from a command line with a syntax error -- both don't contain a regexp match. Stripping whitespace is a workaround for this specific bug, but any other syntax error can possibly cause the same problem.
I've sent a CL to strip whitespaces.

Thank you. @rasky


[Bug]: Error code (WIN32): 126") [.../casadi/core/plugin_interface.hpp:171]

PyBaMM Version
22.10
Python Version
3.8
Describe the bug
2022-11-02 21:40:12.211 - [INFO] base_model._build_model(572): Start building Doyle-Fuller-Newman model
2022-11-02 21:40:12.281 - [INFO] base_battery_model.build_model(1019): Finish building Doyle-Fuller-Newman model
2022-11-02 21:40:12.282 - [INFO] parameter_values.process_model(371): Start setting parameters for Doyle-Fuller-Newman model
2022-11-02 21:40:12.389 - [INFO] parameter_values.process_model(474): Finish setting parameters for Doyle-Fuller-Newman model
2022-11-02 21:40:12.392 - [INFO] discretisation.process_model(149): Start discretising Doyle-Fuller-Newman model
2022-11-02 21:40:12.401 - [INFO] discretisation.remove_independent_variables_from_rhs(1199): removing variable Discharge capacity [A.h] from rhs
2022-11-02 21:40:12.859 - [INFO] discretisation.process_model(271): Finish discretising Doyle-Fuller-Newman model
2022-11-02 21:40:12.860 - [INFO] base_solver.solve(703): Start solving Doyle-Fuller-Newman model with CasADi solver with 'safe' mode
2022-11-02 21:40:12.866 - [INFO] base_solver.set_up(110): Start solver set-up
2022-11-02 21:40:13.107 - [INFO] base_solver.set_up(235): Finish solver set-up
CasADi -  WARNING(".../casadi/core/plugin_interface.hpp:322: Assertion "handle!=nullptr" failed:
PluginInterface::load_plugin: Cannot load shared library 'libcasadi_rootfinder_newton.dll':
   (
    Searched directories: 1. casadipath from GlobalOptions
                          2. CASADIPATH env var
                          3. PATH env var (Windows)
                          4. LD_LIBRARY_PATH env var (Linux)
                          5. DYLD_LIBRARY_PATH env var (osx)
    A library may be 'not found' even if the file exists:
          * library is not compatible (different compiler/bitness)
          * the dependencies are not found
   )
  Tried '...\venv\lib\site-packages\casadi' :
    Error code (WIN32): 126
  Tried '' :
    Error code (WIN32): 126
  Tried '.' :
    Error code (WIN32): 126") [.../casadi/core/plugin_interface.hpp:171]

Steps to Reproduce

import pybamm
import numpy as np

pybamm.set_logging_level("INFO")

# load model
model = pybamm.lithium_ion.DFN()
# create geometry
geometry = model.default_geometry

# load parameter values and process model and geometry
param = model.default_parameter_values
param.process_geometry(geometry)
param.process_model(model)

# set mesh
var = pybamm.standard_spatial_vars
var_pts = {var.x_n: 30, var.x_s: 30, var.x_p: 30, var.r_n: 10, var.r_p: 10}
mesh = pybamm.Mesh(geometry, model.default_submesh_types, var_pts)

# discretise model
disc = pybamm.Discretisation(mesh, model.default_spatial_methods)
disc.process_model(model)

# solve model
t_eval = np.linspace(0, 3600, 100)
solver = pybamm.CasadiSolver(mode="safe", atol=1e-6, rtol=1e-3)
solution = solver.solve(model, t_eval)

# plot
plot = pybamm.QuickPlot(
    solution,
    [
        "Current [A]",
        "Terminal voltage [V]",
    ],
    time_unit="seconds",
    spatial_unit="um",
)
plot.dynamic_plot()

Relevant log output
No response

Looks like a casadi issue. Does this work?
from casadi import *

# Symbols/expressions
x = MX.sym('x')
y = MX.sym('y')
z = MX.sym('z')
f = x**2+100*z**2
g = z+(1-x)**2-y

nlp = {}                 # NLP declaration
nlp['x']= vertcat(x,y,z) # decision vars
nlp['f'] = f             # objective
nlp['g'] = g             # constraints

# Create solver instance
F = nlpsol('F','ipopt',nlp);

# Solve the problem using a guess
F(x0=[2.5,3.0,0.75],ubg=0,lbg=0)

Looks like a casadi issue. Does this work?
from casadi import *

# Symbols/expressions
x = MX.sym('x')
y = MX.sym('y')
z = MX.sym('z')
f = x**2+100*z**2
g = z+(1-x)**2-y

nlp = {}                 # NLP declaration
nlp['x']= vertcat(x,y,z) # decision vars
nlp['f'] = f             # objective
nlp['g'] = g             # constraints

# Create solver instance
F = nlpsol('F','ipopt',nlp);

# Solve the problem using a guess
F(x0=[2.5,3.0,0.75],ubg=0,lbg=0)

Still have an error.

RuntimeError                              Traceback (most recent call last)
Cell In [2], line 17
     14 nlp['g'] = g             # constraints
     16 # Create solver instance
---> 17 F = nlpsol('F','ipopt',nlp);
     19 # Solve the problem using a guess
     20 F(x0=[2.5,3.0,0.75],ubg=0,lbg=0)
File e:\venv\lib\site-packages\casadi\casadi.py:16847, in nlpsol(*args)
  15857 def nlpsol(*args):
  15858     """
  15859
  15860
   (...)
  16845
  16846     """
> 16847     return _casadi.nlpsol(*args)

RuntimeError: .../casadi/core/plugin_interface.hpp:417: Plugin 'ipopt' is not found.

You should open an issue with casadi to figure out how to fix this


Updated for 0.14.12, added config option to load specific map

0.14.12 removed the --autosave-interval and --autosave-slots command line switches, see https://forums.factorio.com/viewtopic.php?f=3&t=3359
Also added SAVE_PATH and START_SERVER_ARG config options for loading a specific map or replacing the --start-server* argument altogether.

Damn, saw #87 too late, feel free to use that one instead. I'll open another pull request for the features after merging.


When using Data consistency feature with On Prem SQL Server as source, getting the following error: "This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms"

[Enter feedback here]

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

ID: 70956e0c-ddec-96a9-e1d4-d25dc54f7a28
Version Independent ID: 385b0054-fc50-a103-0b3d-53aa3fc20e64
Content: Data consistency verification in copy activity - Azure Data Factory
Content Source: articles/data-factory/copy-activity-data-consistency.md
Service: data-factory
GitHub Login: @dearandyxu
Microsoft Alias: yexu

@vikramdadwal  Since this issue is not related directly to the doc, I would recommend you to create a thread on the forums - Microsoft Q&A or Stack Overflow
Once you post your issue on forums, it will have visibility across the community which is a better-suited audience for such types of issues.

Done:  https://stackoverflow.com/questions/65084901/azure-data-factory-copy-activity-error-this-implementation-is-not-part-of-the-w

@vikramdadwal  We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


Pydantic dataclasses

Fixes #74
Closes #75
Closes #68
Closes #63
Use pydantic.dataclasses.dataclass instead of dataclasses.dataclass.
This ensures the *_config attribute is type-checked, meaning one can now sub-class the *Config pydantic model and substitute this in for the specific strategy, updating the configuration field with another strategy-specific model that then automatically will ensure the configuration for the strategy is correct upon strategy initialization.
Mypy has been extended with the pydantic plugin.
The tests have been slightly streamlined.
This PR also implements the beginnings of satisfying #71. However, it doesn't implement an introspection or schema method to fully satisfy #71.

Codecov Report

Merging #81 (c3a8a71) into master (325db5c) will increase coverage by 2.16%.
The diff coverage is 69.48%.

@@            Coverage Diff             @@
##           master      #81      +/-   ##
==========================================
+ Coverage   69.76%   71.93%   +2.16%
==========================================
  Files          34       34
  Lines         807      880      +73
==========================================
+ Hits          563      633      +70
- Misses        244      247       +3

Flag
Coverage Δ

linux
71.93% <69.48%> (+2.16%)
:arrow_up:

windows
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

oteapi/strategies/filter/sql_query_filter.py
0.00% <0.00%> (ø)

oteapi/strategies/parse/excel_xlsx.py
0.00% <0.00%> (ø)

oteapi/strategies/parse/text_csv.py
0.00% <0.00%> (ø)

oteapi/strategies/transformation/celery_remote.py
0.00% <0.00%> (ø)

oteapi/models/genericconfig.py
73.01% <66.66%> (-6.16%)
:arrow_down:

oteapi/strategies/download/file.py
91.17% <89.47%> (+1.89%)
:arrow_up:

oteapi/strategies/parse/application_vnd_sqlite.py
95.34% <97.14%> (+15.34%)
:arrow_up:

oteapi/models/resourceconfig.py
100.00% <100.00%> (ø)

oteapi/plugins/factories.py
100.00% <100.00%> (ø)

oteapi/strategies/download/https.py
86.36% <100.00%> (ø)

... and 10 more

Continue to review full report at Codecov.

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

Will this PR influences OTEAPI-services and OTELIB?

I don't think it should. Everything should be fine from their perspective. But it's difficult to say 100 %. Should be fine though :)

@jesper-friis I have now updated this PR with what we discussed offline concerning having a utility function for converting URI/IRI/URLs to pathlib.Path.


Formula of derived KPIs only support rasios

The following code in Experiment.delta
pattern = '([a-zA-Z][0-9a-zA-Z_]*)'
self.kpis.loc[:,kpiName] = eval(re.sub(pattern, r'self.kpis.\1.astype(float)', dk['formula']))

will only work for fomulas with simple ratios (and also too hacky).
However, I found that some of the KPIs here requires sum/count/>0, etc...

... and using eval on unvalidated input is a potential security breach.


Wait option

Hey,
It would be very cool to have an option to tell to ecs-service-image-updater to wait until the service reached a steady state.
AWS-SDK have this function : https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/ECS.html#servicesStable-waiter

Hi @feraudet, thanks for the issue. I think that's already covered by the other packages related to this one, for example https://github.com/bugcrowd/ecs-deployment-monitor


Having shift click to quickly select a row of tabs instead of checking each box

Hi,
Would it be possible to shift click many lines at once so as to deal with them as a group?
And not just checkbox selection.

Add to the roadmap to be implemented in future releases

I think it's important to follow what is considered the universally ubiqitous input scheme. The more it behaves like you'd expect it to with no prior experience with the extension, the better the usability will be. I've noticed that in extensions, apps etc. where they adopt non-universal UI interraction, it instantly creates a learning curve, making you less likely to use those features and sometimes makes for a less efficient workflow.
Here's what I propose (nothing fancy, just what everyone is used to from before from file managers, mail clients etc.):

Ctrl + Left Click for selecting one by one (does not deselect other selections)

Option to make items selectable without Ctrl, or even default behaviour.
To be able to make selections efficiently, I would prefer to be able to do Ctrl + Left Click anywhere on a tab item. Same for the other selection shortcuts/methods.

Shift + Left Click for selecting a chain of items (from last clicked or selected to the item clicked while holding shift)

Not vital in my opinion: Option to not deselect other selections. Either way, should be default to not deselect in my opinion.

Ctrl + Shift + Left Click for selecting a new chain (like Shift + Left Click without deselecting items outside of the Shift chain).

Should not be affected by the behaviour setting of the other shortcuts

Also, check boxes are small and tedius. This is why I think it's important to be able to hold Ctrl and/or Shift and be able to select by clicking anywhere on the tab item.

I know this conflicts with a shortcut to open tabs in the background. However, I think selection should overrule that feature. If shortcuts were customizable, users who prefer the non-conventional way could get what they prefer too.
However, even if it were to just be changed to this and "open to background"  would be changed to the scroll wheel click, it would still be intuitive for the users using this shortcut. And the inconvenience upon discovering the change for the first time would be non-breaking and have minimal inconvenience.


style elements with a css class bad practice

Challenge Name
https://www.freecodecamp.com/challenges/use-a-css-class-to-style-an-element
Issue Description
The class names .blue-text and .red-text are used, the student is being asked to unnecessarily use colours specifically in the class names which is bad practice. The lesson even requires the student to modify the class name, only because a color name has been used. Instead, the class name should be something agnostic of the color used such as .main-text or similar, meaning that the student learns to maintain only the style value and not the style's underlying class selector unnecessarily.
Browser Information

Browser Name, Version:
Operating System:
Mobile, Desktop, or Tablet:

Your Code

Screenshot

@tombatnz thanks for the issue. Although I would agree with your argument, we've had similar discussions on whether to show best practices or not. From what I remember, we agreed on focusing more on just teaching students how HTML (or whatever concept) works.
Quote from @BerkeleyTrue

On top of that, challenges are meant to teach specific concepts and not necessarily teach best practices.

cc/ @FreeCodeCamp/issue-moderators

I'd agree with @erictleung, I think the specific class names are useful for linking the style definition and class assignment together in the user's mind, and showing what the style rule is for and how it works. As an introduction to the concepts it works well, and best practices can be developed with more practice.

Yeah, we should ideally switch to using more logical naming for the classes.

@erictleung @BKinahan Are correct, challenges are meant to teach a specific concept. Best practices are not something we should teach at such an introductory level.
Happy Coding.


Release - Microsoft SSO Login

Should support mylaurier emails

Failing tests seems inconsistent - one pass and another failed.
This was pushed to staging and seems to be working


FrontEnd : CSS : Transition and transformation (D) - Part 1 (only contains Transforms)

Description 📜
CSS transforms code and documentation with examples.  Will create a 2nd PR for CSS transitions after this because the documentation is too long. Thus total of 2 PR's in this issue.
Fixes #1061

Type of change 📝

[x] Doc#umentation (Content Creation in the form of codes or tutorials)

Domain of Contribution 📊

[x] Frontend Dev HTML/CSS/JS

Checklist ✅

[x] I follow Contributing Guidelines & Code of conduct of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I'm GWOC'21 contributor

Screenshots / Gif (Optional) 📸

Please don't close the issue since I need to make another pr in the same issue. Just merge this one if everything is alright!

https://github.com/girlscript/winter-of-contributing/pull/2606
Here's the Part 2 of the pr

You need to explain more @RC2208, and examples will be really good to include.

Hi! I have done the required changes and added more example images. The readme file was just the summary of both pdfs.... @code-reaper08


Briefcase is missing

briefcase_fill is available but not briefcase, which can be found at https://framework7.io/icons/

I will check it later.🤠 Thanks


 Adding this allows the building / department code to trigger install policies to work.

hey man! looks good but can't automerge. don't have time to look at this right now.. but soon! back in macadmin land man!

I just added 10.12 software update compatibility mate.

Can I get these changes re-pulled against master? it won't automerge and I am too derp to fix. Thanks!

I think you're better off doing a copy + paste ;) But yeah, I'll do a PR against master if you're happy it all works.


⚠ Bofrost.be has degraded performance

In c0fcc7f, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1383 ms

Resolved: Bofrost.be performance has improved in 177b039 after 6 minutes.


chore(cairo_native): grow the stack to handle overflows

This change is

crates/blockifier/src/execution/native/entry_point_execution.rs line 59 at r1 (raw file):

    let stack_size_red_zone = 160 * 1024 * 1024;
    let target_stack_size = stack_size_red_zone + 10 * 1024 * 1024;
    let execution_result = stacker::maybe_grow(stack_size_red_zone, target_stack_size, || {

maybe_grow because of nested calls?
Code quote:
 stacker::maybe_grow(


ToDo: diffs FF79-FF80

FF80 is scheduled for release August 25th
FF80 release notes [when ready]
FF80 for developers
FF80 compatibility
FF80 security advisories

65 diffs ( 40 new, 8 gone, 17 different )
new in v80.0:

[ ] pref("dom.security.https_only_mode_pbm", false);
0207 pref("browser.region.update.enabled", true); - actually added hidden in FF79 - bad earthlng 😀

pref("dom.block_download_insecure", false);
pref("dom.security.unexpected_system_load_telemetry_enabled", true);
pref("security.xfocsp.errorReporting.automatic", false);
pref("security.xfocsp.errorReporting.enabled", true);

removed, renamed or hidden in  v80.0:

changed in  v80.0:
pref("security.allow_disjointed_external_uri_loads", false); // prev: true
pref("signon.backup.enabled", true); // prev: false
pref("signon.capture.inputChanges.enabled", false); // prev: true

ignore
click me for details
==NEW
pref("apz.force_disable_desktop_zooming_scrollbars", true);
pref("browser.preferences.experimental.hidden", false);
pref("browser.preferences.exposeHTTPSOnly", false);
pref("browser.tabs.documentchannel.parent-controlled", false);
pref("browser.topsites.useRemoteSetting", false);
pref("browser.urlbar.loglevel", "Error");
pref("browser.urlbar.update2", false);
pref("browser.urlbar.update2.localOneOffs", false);
pref("browser.urlbar.update2.oneOffsRefresh", false);
pref("browser.urlbar.update2.tabToComplete", false);
pref("devtools.netmonitor.audits.slow", 500);
pref("dom.security.https_only_mode_ever_enabled_pbm", false);
pref("dom.suspend_inactive.enabled", false);
pref("domsecurity.httpsonly.infoURL", "https://developer.mozilla.org/en-US/docs/Glossary/https");
pref("extensions.backgroundServiceWorker.enabled", false);
pref("extensions.formautofill.addresses.capture.enabled", false);
pref("extensions.formautofill.creditCards.hideui", false);
pref("extensions.serviceWorkerRegister.allowed", false);
pref("fission.processOriginNames", false);
pref("gfx.use-ahardwarebuffer-content", false);
pref("layout.animation.prerender.partial.jank", false);
pref("layout.css.prefers-contrast.enabled", false);
pref("media.videocontrols.picture-in-picture.video-toggle.has-used", false);
pref("media.videocontrols.picture-in-picture.video-toggle.mode", -1);
pref("media.videocontrols.picture-in-picture.video-toggle.position", "right");
pref("print.tab_modal.enabled", false);
pref("security.bad_cert_domain_error.url_fix_enabled", false);
pref("security.ssl3.rsa_aes_128_gcm_sha256", true);
pref("security.ssl3.rsa_aes_256_gcm_sha384", true);
pref("security.warn_submit_secure_to_insecure", true);
pref("signon.management.page.fileImport.enabled", false);
pref("storage.sqlite.exclusiveLock.enabled", true);
pref("webgl.debug.incomplete-tex-color", 0);
pref("webgl.oop.via-pcq", false);

==REMOVED or HIDDEN
pref("browser.urlbar.update2.expandTextOnFocus", false);
pref("devtools.accessibility.auto-init.enabled", true);
pref("devtools.responsive.browserUI.enabled", true);
pref("dom.sidebar.enabled", false);
pref("layout.viewport_contains_no_contents_area", true);
pref("media.getusermedia.experimental_input_processing", false);
pref("network.standard-url.punycode-host", true);
pref("webgl.prototype.ipc-pcq", 0);

==CHANGED
pref("apz.mvm.force-enabled", true); // prev: false
pref("browser.aboutwelcome.overrideContent", "{\"id\": \"multi-stage-welcome-default\",\"template\": \"multistage\",\"screens\": [{\"id\": \"AW_GET_STARTED\",\"order\": 0,\"content\": {\"zap\": true,\"title\": {\"string_id\": \"onboarding-multistage-welcome-header\"},\"subtitle\": {\"string_id\": \"onboarding-multistage-welcome-subtitle\"},\"primary_button\": {\"label\": {\"string_id\": \"onboarding-multistage-welcome-primary-button-label\"},\"action\": {\"navigate\": true}},\"secondary_button\": {\"text\": {\"string_id\": \"onboarding-multistage-welcome-secondary-button-text\"},\"label\": {\"string_id\": \"onboarding-multistage-welcome-secondary-button-label\"},\"position\": \"top\",\"action\": {\"type\": \"OPEN_URL\",\"addFlowParams\": true,\"data\": {\"args\": \"https://accounts.firefox.com/?service=sync&action=email&context=fx_desktop_v3&entrypoint=activity-stream-firstrun&style=trailhead\",\"where\": \"current\"}}}}}, {\"id\": \"AW_IMPORT_SETTINGS\",\"order\": 1,\"content\": {\"zap\": true, \"disclaimer\": {\"string_id\": \"onboarding-import-sites-disclaimer\"},\"title\": {\"string_id\": \"onboarding-multistage-import-header\"},\"subtitle\": {\"string_id\": \"onboarding-multistage-import-subtitle\"},\"tiles\": {\"type\": \"topsites\",\"info\": true},\"primary_button\": {\"label\": {\"string_id\": \"onboarding-multistage-import-primary-button-label\"},\"action\": {\"type\": \"SHOW_MIGRATION_WIZARD\",\"navigate\": true}},\"secondary_button\": {\"label\":  {\"string_id\": \"onboarding-multistage-import-secondary-button-label\"},\"action\": {\"navigate\": true}}}}, {\"id\": \"AW_CHOOSE_THEME\",\"order\": 2,\"content\": {\"zap\": true,\"title\":  {\"string_id\": \"onboarding-multistage-theme-header\"},\"subtitle\": {\"string_id\": \"onboarding-multistage-theme-subtitle\"},\"tiles\": {\"type\": \"theme\",\"action\": {\"theme\": \"<event>\"}, \"data\": [{\"theme\": \"automatic\",\"label\": {\"string_id\": \"onboarding-multistage-theme-label-automatic\"}, \"description\": {\"string_id\": \"onboarding-multistage-theme-description-automatic\"}, \"tooltip\": {\"string_id\": \"onboarding-multistage-theme-tooltip-automatic\"}}, {\"theme\": \"light\",\"label\": {\"string_id\": \"onboarding-multistage-theme-label-light\"}, \"tooltip\": {\"string_id\": \"onboarding-multistage-theme-tooltip-light\"}},{\"theme\": \"dark\",\"label\": {\"string_id\": \"onboarding-multistage-theme-label-dark\"}, \"tooltip\": {\"string_id\": \"onboarding-multistage-theme-tooltip-dark\"}}]},\"primary_button\": {\"label\": {\"string_id\": \"onboarding-multistage-theme-primary-button-label\"},\"action\": {\"navigate\": true}},\"secondary_button\": {\"label\": {\"string_id\": \"onboarding-multistage-theme-secondary-button-label\"},\"action\": {\"theme\": \"automatic\",\"navigate\": true}}}}]}"); // prev: ""
pref("browser.newtabpage.activity-stream.discoverystream.personalization.version", 2); // prev: 1
pref("browser.newtabpage.activity-stream.discoverystream.region-layout-config", "US,CA,GB,DE,IE"); // prev: "US,CA,GB,DE"
pref("browser.newtabpage.activity-stream.discoverystream.region-stories-config", "US,DE,CA,GB,IE"); // prev: "US,DE,CA,GB"
pref("dom.animations-api.compositing.enabled", true); // prev: false
pref("dom.arena_allocator.enabled", true); // prev: false
pref("dom.max_chrome_script_run_time", 0); // prev: 20
pref("extensions.blocklist.useMLBF", true); // prev: false
pref("extensions.blocklist.useMLBF.stashes", true); // prev: false
pref("identity.sync.useOAuthForSyncToken", true); // prev: false
pref("media.navigator.video.use_transport_cc", true); // prev: false
pref("media.peerconnection.video.use_rtx", true); // prev: false
pref("media.peerconnection.video.use_rtx.blocklist", ""); // prev: "*.google.com"

some bugzilla tickets

apz.force_disable_desktop_zooming_scrollbars
Bug 1655160. Disable new desktop zooming scrollbar code for now.
Bug 1651332. Create a pref to gate the new scrollbar code on.

apz.mvm.force-enabled
Bug 1648687 - Disable the visual-viewport-only MVM for Firefox 79.
Bug 1644271 - Enable the MVM pref by default.
Bug 1644271 - Add a pref to enable the MobileViewportManager.

browser.aboutwelcome.overrideContent
Bug 1656631 - Make static sites in import screen as default experience.
Bug 1653322 - Converted import topsites "disclaimer" tooltip to a footer
Bug 1653087 - Add default theme as an option to multistage choose a theme screen
Bug 1649292 - Make multistage about:welcome as default UX
Bug 1637079 - Initial multi stage about:welcome layout

browser.newtabpage.activity-stream.discoverystream.personalization.version
Bug 1644890 - newtab stories v2 targeting on by default
Bug 1644889 - Turn on newtab story targeting v2 in nightly.

browser.newtabpage.activity-stream.discoverystream.region-layout-config
Bug 1657530 - Enable Ireland region for newtab stories.
Bug 1653061 - turn on 7 rows of pocket stories in the de locale
Bug 1653061 - turn on 7 rows of pocket stories in the de locale.
Bug 1632574 - Turn Pocket stories on by default in GB
Bug 1632574 - Turn Pocket stories on by default in GB.

browser.newtabpage.activity-stream.discoverystream.region-stories-config
Bug 1657530 - Enable Ireland region for newtab stories.
Bug 1632574 - Turn Pocket stories on by default in GB
Bug 1632574 - Turn Pocket stories on by default in GB.

browser.preferences.experimental.hidden
Bug 1648222 - Hide the experimental features category if there are no available experimental features.

browser.preferences.exposeHTTPSOnly
Bug 1644152: Expose HTTPS-Only Mode in about:preferences.

browser.region.update.enabled
Bug 1651124 - Enable region cachebusting on release
Bug 1627555 - Update region if in new location for a length of time.

browser.tabs.documentchannel.parent-controlled
Bug 1647557 - Add preffed-off code for controlling document loads directly from CanonicalBrowsingContext.

browser.topsites.useRemoteSetting
Bug 1653932 - Add pref for top site defaults from remote settings.

browser.urlbar.loglevel
Bug 1650099 - Unify UrlbarProviders logger boilerplate.

browser.urlbar.update2
Bug 1647930 - Create urlbar.update2 prefs.

browser.urlbar.update2.expandTextOnFocus
Bug 1647930 - Create urlbar.update2 prefs.

browser.urlbar.update2.localOneOffs
Bug 1647930 - Create urlbar.update2 prefs.

browser.urlbar.update2.oneOffsRefresh
Bug 1647930 - Create urlbar.update2 prefs.

browser.urlbar.update2.tabToComplete
Bug 1647930 - Create urlbar.update2 prefs.

devtools.accessibility.auto-init.enabled
Bug 1640778 - remove auto-init experiment code.
Bug 1642520 - enable accessibility panel auto initialization on all channels.
Bug 1602075 - add an accessibility-panel-auto-init feature to control the panel auto enabling functionality.

devtools.netmonitor.audits.slow
Bug 1648373 - Add slow requests indicator

devtools.responsive.browserUI.enabled
Bug 1585097 - Delete the devtools.responsive.browserUI.enabled pref.
Bug 1585005  - Enable RDM Fission for all builds.
Bug 1621306 - Enable the devtools.responsive.browserUI.enabled pref in Nightly only

dom.animations-api.compositing.enabled
Bug 1652676 - Enable Web Animations API compositing operations on release channels;

dom.arena_allocator.enabled
Bug 1652496 - Enable DOM arena allocation in Release

dom.block_download_insecure
Bug 1614969 - Check download with MixedContentBlocker

dom.max_chrome_script_run_time
Bug 1654325 - disable the parent process slow script dialog,

dom.security.https_only_mode_ever_enabled_pbm
Bug 1647719: Introduce Pref for HTTS-Only in Private Browsing Mode.

dom.security.https_only_mode_pbm
Bug 1647719: Introduce Pref for HTTS-Only in Private Browsing Mode.

dom.security.unexpected_system_load_telemetry_enabled
Bug 1644671 - systemprincipal restrictions telemetry

dom.sidebar.enabled
Bug 1632448 - Remove AddSearchProvider implementation.

dom.suspend_inactive.enabled
Bug 1639577 - Only suspend GeckoView tabs that are alone in their BrowsingContextGroup

domsecurity.httpsonly.infoURL
Bug 1644152: Expose HTTPS-Only Mode in about:preferences.

extensions.backgroundServiceWorker.enabled
Bug 1609920 - part 1: Allow the WebExtension Framework to register a moz-extension service worker.

extensions.blocklist.useMLBF
Bug 1620621 - Implement blocklist stashing behind pref
Bug 1620621 - Add bloomfilter-based blocklist for addons
Bug 1631018 - Enable blocklist v3 by default on desktop

extensions.blocklist.useMLBF.stashes
Bug 1620621 - Implement blocklist stashing behind pref
Bug 1631018 - Enable blocklist v3 by default on desktop

extensions.formautofill.addresses.capture.enabled
Bug 1626055 - Disable address autofill auto-saving until we deal with duplicate addresses.

extensions.formautofill.creditCards.hideui
Bug 1658027 - Separate visual interactions on Credit Card Autofill for A/B testing.

extensions.serviceWorkerRegister.allowed
Bug 1609920 - part 2: Guard ServiceWorkerContainer::Register to allow/disallow moz-extension scheme based on prefs.

fission.processOriginNames
Bug 1642772: Add fission process renaming to eTLD+1 for Nightly (only) via a pref

gfx.use-ahardwarebuffer-content
Bug 1648411 - Add AHardwareBuffer layer buffer support on android

identity.sync.useOAuthForSyncToken
Bug 1648194 - Enable 'identity.sync.useOAuthForSyncToken' for all users.
Bug 1635937 - Enable 'identity.sync.useOAuthForSyncToken' pref for Nightly users
Bug 1631830 - Fetch Sync tokens with OAuth behind a pref

layout.animation.prerender.partial.jank
Bug 1324591 - Report janked animations to the main-thread and update them on the main-thread.

layout.css.prefers-contrast.enabled
Bug 1506364 - Implement the prefers-contrast media-query.

layout.viewport_contains_no_contents_area
Bug 1650686 - Drop layout.viewport_contains_no_contents_area.

media.getusermedia.experimental_input_processing
Bug 1646660 - Disable cheaper processing made in bug 1628779.
Bug 1628779 - Pass the audio rountrip latency to the echo canceller, and disable extended filter and delay agnostic AEC, on macOS Nightly.

media.navigator.video.use_transport_cc
Bug 1651722 - Enable transport-cc and rtx and let them ride the trains;
Bug 1625803 - Enable transport-cc extension for nightly and early beta;
Bug 1606823 - Add support for WebRTC transport-cc extension.

media.peerconnection.video.use_rtx
Bug 1651722 - Enable transport-cc and rtx and let them ride the trains;
Bug 1641600 - Re-enable rtx and add *.google.com to blocklist;
Bug 1638758 - Turn off just-added media.peerconnection.video.use_rtx in nightly.
Bug 1632489 - Enable rtx for early beta or earlier;
acked out 4 changesets (bug 1632489) for android crashes at test_peerConnection_maxFsConstraint.html. CLOSED TREE
Bug 1164187 - Add pref for rtx;

media.peerconnection.video.use_rtx.blocklist
Bug 1651722 - Enable transport-cc and rtx and let them ride the trains;
Bug 1641600 - Re-enable rtx and add *.google.com to blocklist;

media.videocontrols.picture-in-picture.video-toggle.has-used
Bug 1653663 - Add experimental Picture-in-Picture toggle variations.

media.videocontrols.picture-in-picture.video-toggle.mode
Bug 1653663 - Add experimental Picture-in-Picture toggle variations.

media.videocontrols.picture-in-picture.video-toggle.position
Bug 1653663 - Add experimental Picture-in-Picture toggle variations.

network.standard-url.punycode-host
Bug 1637727 - convert network.standard-url.punycode-host to a StaticPref.
Bug 1653201 - Remove internal nsStandardURL punycode pref

print.tab_modal.enabled
Bug 1652627 - Setup a pref for tab modal print UI

security.allow_disjointed_external_uri_loads
Bug 1650162 - Turn security.allow_disjointed_external_uri_loads back on to fix regressions opening external applications.
Bug 1606797 - do not allow navigating to external URIs in cross-origin disjoint browsing contexts,

security.bad_cert_domain_error.url_fix_enabled
Bug 1656253 - disable security.bad_cert_domain_error.url_fix_enabled in late beta and release.
Bug 1617987 - Fix URLs by prefixing www. when users encounter bad cert domain errors.

security.ssl3.rsa_aes_128_gcm_sha256
Bug 1641356 - Unhide RSA-AES-GCM ciphersuite preferences

security.ssl3.rsa_aes_256_gcm_sha384
Bug 1641356 - Unhide RSA-AES-GCM ciphersuite preferences

security.warn_submit_secure_to_insecure
Bug 436200 - Add a pref to turn off warning submitting secure to insecure.

security.xfocsp.errorReporting.automatic
Bug 1647825 - Part 1: Add the UI for enable reporting XFO and CSP:frame-ancestors error.

security.xfocsp.errorReporting.enabled
Bug 1647825 - Part 1: Add the UI for enable reporting XFO and CSP:frame-ancestors error.

signon.backup.enabled
Bug 1593467 - Automatically restore from logins-backup.json when logins.json is missing or corrupt.
Bug 1597358 - Create a backup of logins.json to use when logins.json is missing or corrupt.

signon.capture.inputChanges.enabled
Bug 1654405 - pref doorhanger v2 off outside Nightly;r=MattN
Bug 1641412 - Pass all possible UNs/PWs to doorhanger;r=MattN,sfoster

signon.management.page.fileImport.enabled
Bug 1654604 - Hold CSV Import to Nightly for Fx80.

storage.sqlite.exclusiveLock.enabled
Bug 1650201 - Fix mozStorage prefs read before profile and fallback to a non-exclusive VFS when it can't get an exclusive lock.

webgl.debug.incomplete-tex-color
Bug 1649894 - Add webgl.debug.incomplete-tex-color.

webgl.oop.via-pcq
Bug 1607940 - Stand up webgl.out-of-process:true path.

webgl.prototype.ipc-pcq
Bug 1607940 - Stand up webgl.out-of-process:true path.

browser.region.update.enabled - https://github.com/ghacksuserjs/ghacks-user.js/issues/978#issuecomment-665589158
re: 1244 suggestions - the SETTING line already has (FF81+). Assuming they'll flip exposeHTTPSOnly in FF81, I think that's fine.
Yes we can add https_only_mode_pbm. The one we already have, https_only_mode, enables HOM for both normal and private windows, whereas the new one enables it for private windows only.
If https_only_mode is true, https_only_mode_pbm is ignored

browser.region.update.enabled is set to true for FF80 as per this commit. Relevant bug.

security.xfocsp.errorReporting.* - https://bugzilla.mozilla.org/show_bug.cgi?id=1647825#c9:

The reporting is disabled by default. When users hit an XFO or a CSP error page, there is a checkbox UI to allow user opt-in the reporting. Once users check the checkbox, we will start to report. So, we will report every time users hit an XFO or CSP error page. And users can opt-out the reporting by unchecking the checkbox. After that, we will no longer report the error.

screenshot of the error page with the checkbox: https://bug1647825.bmoattachments.org/attachment.cgi?id=9162074
"The reporting is disabled by default" = security.xfocsp.errorReporting.automatic=false
Checking the checkbox flips the .automatic pref to true.
Setting security.xfocsp.errorReporting.enabled to false hides the checkbox.
Uses normal telemetry ping (which we disable) and "The client_id and environment are not sent with this ping."
So in our case the checkbox does nothing and we could include these 2 prefs to (1) make sure the reporting is disabled and (2) the checkbox is not visible. Or just move them to ignore

security.allow_disjointed_external_uri_loads - caused some regressions initially but they apparently think it's ready now after landing some fixes in FF80.
# Whether window A is allowed to navigate cross-origin window B (that is not
# a descendant frame of A) to a URI that loads externally.

source
"allow...=false" is what we want. move to ignore IMO

Assuming they'll flip exposeHTTPSOnly in FF81, I think that's fine.

I doubt it will land in FF81 .. it's not even going to be dev/beta 81 (99% sure, but I'll wait for dev/beta 81 to land to comfirm) - there are too many blockers IMO.
My thinking now is we just remove it and wait for the pref to get flipped (or removed) in stable and that's out reminder to add the [setting] tag

I did a PR .. I don't mind what I did there, or we can rip it out

security.xfocsp.errorReporting.* ... So in our case the checkbox does nothing and we could include these 2 prefs to (1) make sure the reporting is disabled and (2) the checkbox is not visible. Or just move them to ignore

I'm 51/49 in favor of ignoring ... I typed out the discussion in my head and got nowhere: tl;dr you and I are fine, and we will always pick up if the automatic pref is flipped, and the less stuff in the user.js the better. That said, defence in depth is good, especially since URIs would be recorded and that data would be kept (I think: I'm not sure what happens when the pings fails - are you talking about browser.ping-centre.telemetry in 0506?)
The choice is yours @earthlng

I'm 51/49 in favor of ignoring

I agree. It's opt-in and the worst that could happen is someone willingly opting-in to help Mozilla identify and block malicious sites and ending up not sending anything because we have all telemetry disabled.
Even if it would send a ping somehow, "the client_id and environment are not sent with this ping." and thus the only potentially linkable/identifiable "id" would be the IP and IDK if they record/store that. But even if they do record and/or store that - it's opt-in!

source

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/80 unexciting (which is actually a feature)

LOL

what's left

A; new: pref("dom.block_download_insecure", false);
B: new: pref("dom.security.unexpected_system_load_telemetry_enabled", true);
C: changed: pref("signon.backup.enabled", true); // prev: false
D: changed: pref("signon.capture.inputChanges.enabled", false); // prev: true

C: ignore IMO: a local backed up passwords file is (probably) no more dangerous than having the original. I haven't read anything about it, so I don't know if it keeps multiple copies or how often or if it's triggered when you add/remove passwords. But it can't hurt for end users, except that if you removed the account details for secretplace.com, there could still be a record of it. We're getting a bit edge case here.
D: NFI : feel free to look up if it's harmless
A: this has some regressions. I wouldn't expect any of our users to get HTTP downloads on secure pages. We could either wait for it to get flipped, or add it now (because who knows if it will take 14 releases to get flipped like noopener)
B:E said : should be covered by disabling telemetry but there's an unfixed regression causing a crash, so maybe we should disable this

IMO ignore it: if crashes were that bad, Moz would do a point release

tl;dr: B,C,D = ignore; A = ignore and make a note (new issue as reminder) to revisit in 3 or 4 releases
@earthlng and co, wot say you

D: commit - Bug.  ¯\_(ツ)_/¯

^^ Thanks. Sorry for my laziness .. I know the relevant bugzillas are listed by earthlng: and I see most bugs because every day or so I check out all landed bugs as I look for possible version feature detection items.
D: Ahhh, yeah, we can ignore that

I wouldn't expect any of our users to get HTTP downloads on secure pages.

HTTP downloads are still common if mirrors are used because of big downloads.
This pref is on about:config but not in dxr. :rofl:  LOL.

I linked the ticket above, and I have read of regressions (like downloads folder has wrong info, no notifications etc) of which some/all are now fixed .. so I was just going to ignore it for now and see if it was flipped on in a couple of releases
I was trying to find a meta ticket, but I didn't try very hard

Here's a bit of a dig around
Depends on

1654780 drag and drop bypasses

Regressions

open 1654139 silent failure to DL
fixed 82: 1656296 = add indicator for blocked downloads
open 1660969 ship panel/button to manually confirm/override block
open 1660952 probable duplicate or may be windows only

Lots of others marked as duplicates

pdfs not loading (if not viewed internally)
other DLs nothing happens or insecure warnings

One of the comments in one of those tickets says telemetry indicates about 10% of downloads initiated from secure sites are insecure. So I guess they just need to get user notification and manual overrides working, and the we can flip it on


Some evidence statements still appear under user "Admin"

Do we know why some evidence statements still appear as last modified by Admin despite showing as being created by a specific user in the spreadsheet? Here is just one example. I was able to find several.
https://civic.genome.wustl.edu/#/events/genes/18/summary/variants/32/summary/evidence/4/summary

Yeah, I talked about it briefly in the meeting on Wednesday, but its basically instances where what's on the site has diverged from what's in the spreadsheet. For instance, in that example, the statement text doesn't exist in the spreadsheet. I did some work last week and this weekend that should let me match up items that have diverged based on their edit history and allow for a more complete backfill, so these instances should be largely eliminated in the next day or so.

Ah right. I remember now.

Fixed in the new build process!

Wrong issue.

Just checking in on this one.  In the latest public version, many evidence items no longer show "Admin", but these now show nothing at all.

On the other hand, variant summaries do show who last modified them, but almost all show "Created by Admin".

All Evidence Items should now have both a submitted by and an accepted by! Admin is still cropping up in some of the variant and gene summaries and I'm taking a look at that now.