chore(main): release 0.1.0

:robot: I have created a release beep boop
0.1.0 (2024-06-28)
⚠ BREAKING CHANGES

pin dependency version in all wrapper conda env yamls (#492)
broken plot generation for the control_freec tool in the somatic_wgs_cnv_calling step, and the sample selection for the mutect2 panel_of_normal generation can be based on a user-generated file.
use snakemake tmpdir resource (#319) (#320)
merge wgs_{sv,cnv,mei}_calling into sv_calling_wgs (#275) (#315)
merge {variant,wgs_{sv,cnv}}_calling_export into varfish_export (#308) (#309)
move "bcftools roh" as report in variant_calling (#310) (#311)
rename targeted_seq_cnv_calling to sv_calling_targeted (#305) (#306)
rename helper_gcnv_model_target_seq to helper_gcnv_targeted (#303) (#304)

Features

(430) picard metrics for bam files (#431) (35b24cd)
237 revive cnvkit (#339) (bc4c55b)
385 cbioportal export wrapper missing information (#411) (0ac31e8)
438 vep annotation order (#441) (c28d67e)
add CI for a scaled down version of a cancer WES pipeline (#499) (b971088)
add delly2 and manta for sv_calling_targeted (#277) (#307) (99dae5f)
add missense TMB calculation (#432) (4fd0c73)
Added support for scarHRD (#429) (c5f9dde)
added vep to the somatic variant annotation tools (#384) (35cbe09)
adding bwa_mem2 wrapper (#279) (#312) (1374418)
Adding tmb calculation  (#403) (706a9f5)
allow helper_gcnv_model_target_seq to build for multiple kits at the same time (#285) (#293) (efe6539)
also write out mapping quality bigWig file (#476) (#480) (dc1d92b)
annotating SV coverage with varfish-annotator (#371) (e9fb880)
bringing back variant_annotation with VEP (#386) (#387) (d4ac11e)
bump and fix Mehari for SVs in varfish_export (#444) (0ca23f6)
bump ngs-chew to 0.6.x, adding aafs to output (#317) (feb13a3)
bump ngs-chew to 0.7 (#334) (7f1fa1a)
bump ngs-chew to v0.9.x (#478) (c54bba1)
bump varfish-annotator to v0.32 (#365) (3239564)
bump varfish-annotator-cli to v0.30 (#314) (#336) (3d045e6)
change varfish-annotator to mehari (#392) (#393) (c86c665)
feature-complete end-to-end run of the Becnel dataset on hs37d5 & GRCh38.d1.vd1 (#460) (4874074)
Fixing Mantis (#427) (e008e7e)
implement ngs_mapping fingerprinting (#283) (#289) (a3303ac)
Initial implementation of Molecular bar codes handling using AGeNT (#462) (768dded)
integrate GATK4 HaplotypeCaller (#287) (#299) (2aeaa01)
make germline variants pon optional for mutect2 (#375) (30bc591)
make ngs_mapping sub steps generate links (#291) (#294) (6f2edd7)
melt for sv_calling_targeted (#321) (13ee84b)
merge {variant,wgs_{sv,cnv}}_calling_export into varfish_export (#308) (#309) (7c35ec3)
merge gCNV output in case of multi-kit families (#292) (#465) (ee64a98)
ngs_mapping cleanup, versions bump (#278) (#280) (af8e21f)
parallel execution in gatk4_hc_gvcf combine_gvcfs and genotype (#318) (4e888e0)
path_exon_bed can be provided independent of data type (#389) (#390) (7759d4d)
PureCN implementation (#453) (e394e8c)
remove legacy variant callers (#295) (#297) (fa2fc6c)
remove plot-bamstats (#288) (#290) (125b601)
replacing custom coverage QC scripts with "alfred qc" (#481) (#482) (ae8fe98)
Somatic cnv checking (#426) (18217bc)
support for snakemake --batch, pipeline.sh for array jobs (#325) (#326) (6ffa5cc)
support for somatic variant calling without normal (#503) (66f555c)
switch GATK 3 HC/UG to GNU parallel based multithreading (#301) (#302) (e23e300)
upgrade to GATK v4.3.0 for gCNV variant calling (#218) (#265) (372464e)
use filtered variants in tmb and signatures (#470) (3e3cead)
use snakemake tmpdir resource (#319) (#320) (c8512b0)

Bug Fixes

355 wgs svcnv export external are also affected by changes in the wrapper for varfish annotator (#356) (a660bda)
Add bwa to mbcs meta-tool environment, closes #518 (b3305c5)
add missing mask_duplicates to bwa_mem2 wrapper (#324) (c5cc7a0)
adjust STAR to new ngs_mapping (#366) (#367) (65c5b6e)
adjustment of manta wrapper for sv_calling_wgs (#351) (e2cd197)
allow to pass single batch number to pipeline_job.sh (#327) (#333) (1c09320)
Always include alfred qc files in input for varfish export bam QC #511 (#516) (d13e595)
bump mehari to 0.21.1 fixes effect prediction (#474) (c0ba296)
bump mehari to v0.25.5 for bugs fixed there (#510) (95b451b)
bump melt memory further (#374) (fad1ad6)
bump time of ngs_mapping/bam_collect_doc (#394) (04551d5)
bwa_mem2 wrapper only used right read (#316) (53c88aa)
check whether gCNV is enabled correctly (#357) (e5ec1b3)
computation of MD5 sums in gatk4_hc genotype wrapper (#338) (0900d9d)
conda env for merge_multikit_families - install attrs package over attr (#487) (fab3e36)
correct name of annotate_svs in Snakefiles (#344) (#345) (f1355ae)
definition of gcnv conda enviroment for mamba>=1.3 (#452) (#454) (50d0781)
do not expect md5 sums for make_vcf step of melt (#323) (65b45bd)
eb_filter wrapper assuming ANN/CSQ is present (#506) (4dc4948)
enforce ploidy in GATK gCNV ploidy calling wrapper (#377) (f244691)
explicitely enable conda when mamba is disabled (#343) (20bb62c)
explicitly require gawk in mutect2/filter wrapper environment (#498) (6993233)
fix somatic snappy (#477) (#491) (af961cc)
fix trimadap-mt & bbduk java version (#446) (46b2303)
fixes multiple issues with the recent cbioportal export changes (#425) (740dda5)
Fixing feature-effects compression (#440) (98825db)
fixing gatk4_hc combine_gvcfs wrapper (e489d93)
fixing problem in running varfish-export (#378) (6d95d88)
gcnv contig wrapper scripts do not clean their output folders (#443) (#468) (618f10d)
gcnv wrapper regex curly-brackets parsed by python string formatting (#489 ) (#501) (8fb40e5)
get_output_files from ngs_mapping as reused in variant_export_external (#346) (f4fcd7e)
give Delly more memory (#373) (05f7988)
give melt more memory (#372) (33785b2)
icrease allowed running time of gCNV jobs (#349) (78521f5)
integration of gcnv and melt into sv_calling_wgs (#350) (5ecad1a)
interpret skip_libraries in sv_calling (#383) (60be51d)
make GNU parallel more robust with --plain and --workdir (#328) (#331) (5a4c39b)
making compatible with varfish export and mehari (#420) (a40a42d)
manta germline_targeted wrapper (#361) (8e718c2)
mehari wrapper vcf preprocessing does not actually fix info svlen header (#450) (#451) (55146c7)
melt wrappers (#335) (66fcd46)
missing check for has_annotation in somatic_variant_filtration rules (#505) (d7420f7)
output pattern problem in gatk4_hc/genotyper wrapper (#329) (3d9555d)
paths in gcnv wrappers (#380) (fcece11)
pin dependency joblib of gcnv (#412) (02fa2da)
pin dependency version in all wrapper conda env yamls (#492) (79499d9)
popdel wrappers (#362) (07d73f4)
re-enabling and fixing Popdel (#359) (b28ed75)
remove "tar results" from manta wrappers (#376) (9717be7)
remove hard coded contig names from gcnv wrappers (#489 ) (#490) (4b89594)
remove some incorrectly expected MELT output (1e24712)
set locale to C in bcftools/TMB wrapper (#507) (9789a2d)
setup.py had reference to removed script (#330) (30447bd)
sleep a random time to work around GNU parallel bug (#328) (#337) (de9f2df)
sleep syntax in Manta wrappers (#358) (e50d4d4)
solve issues with variant_export_external and re-enable wgs_cnv_export_external (#354) (47d9e33)
update snakemake version requirements (#398) (427803c)
use local /tmp directory in gcnv wrapper (#363) (cf052c7)
use only one thread for MELT (#322) (ee84aa4)
various fixes to make gCNV work properly for WGS and targeted (#370) (14d86e3)
write out pedigrees was missing for sv_calling_wgs (#379) (573c72f)
zcat usage in bwa_mem2 wrapper (#364) (9cc0bb2)

Reverts

not using parallel --workdir (#328) (#332) (4cd1531)

Documentation

add warning for writing new workflow steps (#400) (ac1a34f)

Code Refactoring

merge wgs_{sv,cnv,mei}_calling into sv_calling_wgs (#275) (#315) (fa7d0e1)
move "bcftools roh" as report in variant_calling (#310) (#311) (ee7e1fa)
rename helper_gcnv_model_target_seq to helper_gcnv_targeted (#303) (#304) (3f36328)
rename targeted_seq_cnv_calling to sv_calling_targeted (#305) (#306) (e234160)

This PR was generated with Release Please. See documentation.

coverage: 85.999%. remained the same
when pulling b14c08af29c0361726e3c4be0f9d15945dbedd7c on release-please--branches--main
into be0ac092b9077e535f360d6ea41613725d662669 on main.

:robot: Created releases:

v0.1.0
:sunflower:


jumbotron image won't show up when webpage is viewed in one-column

See screenshot below. Essentially, the jumbotron image won't display on a cellphone screen. Any solutions? Thanks.

Yes, thanks for reporting. Update coming today.

Fixed!


Extend azure-core-cpp 1.10 patch for tiledb

Checklist

[x] Used a static YAML file for the patch if possible (instructions).
[x] Ran pre-commit run -a and ensured all files pass the linting checks.
[ ] Ran python show_diff.py and posted the output as part of the PR.
[x] Modifications won't affect packages built in the future.

Follow up to #639. I patched the run exports max pin for azure-core-cpp 1.11.0 in https://github.com/conda-forge/azure-core-cpp-feedstock/pull/11. However, tiledb still needs to use azure-core-cpp 1.10.0 at runtime, so tiledb 2.19.1 was built and tested against 1.10.3 (https://github.com/conda-forge/tiledb-feedstock/pull/233), but it now failing at runtime since it gets installed with the recently re-uploaded azure-core-cpp 1.11.0.
To prevent this problem in the future, I backported the max_pin update to azure-core-cpp 1.10.3 in https://github.com/conda-forge/azure-core-cpp-feedstock/pull/12. Thus the next time that tiledb is built against azure-core-cpp 1.10.3, the run exports will ensure it installs 1.10.3 at runtime.
Note that I considered a more expansive option to patch all conda recipes that depend on azure-core-cpp 1.10 (eg like this recent example to patch a run exports). However, users have only reported a problem with tiledb on linux, so I am limiting the patching to known problems.

Here's the local diff for linux-64. As expected, it shows the new 2.19.1 binaries that weren't covered by the previous patch. I'll post the full show_diff once it's ready from the CI run
python show_diff.py --subdirs linux-64
================================================================================
================================================================================
linux-64
linux-64::tiledb-2.19.1-h4386cac_0.conda
linux-64::tiledb-2.19.1-hc0b898c_0.conda
linux-64::tiledb-2.19.1-h584b59b_0.conda
-    "azure-core-cpp >=1.10.3,<2.0a0",
+    "azure-core-cpp >=1.10.3,<1.11.0a0",

Thanks @xhochy! I was just about to paste the full diff. To keep a record, here it is:
noarch
================================================================================
linux-armv7l
================================================================================
linux-aarch64
linux-aarch64::tiledb-2.19.1-h2d7fb0a_0.conda
linux-aarch64::tiledb-2.19.1-hf61e980_0.conda
linux-aarch64::tiledb-2.19.1-h6acf51b_0.conda
-    "azure-core-cpp >=1.10.3,<2.0a0",
+    "azure-core-cpp >=1.10.3,<1.11.0a0",
================================================================================
linux-64
linux-64::tiledb-2.19.1-hc0b898c_0.conda
linux-64::tiledb-2.19.1-h584b59b_0.conda
linux-64::tiledb-2.19.1-h4386cac_0.conda
-    "azure-core-cpp >=1.10.3,<2.0a0",
+    "azure-core-cpp >=1.10.3,<1.11.0a0",
================================================================================
linux-ppc64le
linux-ppc64le::tiledb-2.19.1-h7b0036b_0.conda
linux-ppc64le::tiledb-2.19.1-ha7f9dc6_0.conda
linux-ppc64le::tiledb-2.19.1-h595b711_0.conda
-    "azure-core-cpp >=1.10.3,<2.0a0",
+    "azure-core-cpp >=1.10.3,<1.11.0a0",
================================================================================
osx-arm64
osx-arm64::tiledb-2.19.1-h49d9ff7_0.conda
osx-arm64::tiledb-2.19.1-h39064d6_0.conda
osx-arm64::tiledb-2.19.1-h7f70256_0.conda
-    "azure-core-cpp >=1.10.3,<2.0a0",
+    "azure-core-cpp >=1.10.3,<1.11.0a0",
================================================================================
win-32
================================================================================
osx-64
osx-64::tiledb-2.19.1-h8fd0293_0.conda
osx-64::tiledb-2.19.1-hee4a7ef_0.conda
osx-64::tiledb-2.19.1-he01210c_0.conda
-    "azure-core-cpp >=1.10.3,<2.0a0",
+    "azure-core-cpp >=1.10.3,<1.11.0a0",
================================================================================
win-64
win-64::tiledb-2.19.1-hf67ed3d_0.conda
win-64::tiledb-2.19.1-h2657894_0.conda
win-64::tiledb-2.19.1-hf016803_0.conda
-    "azure-core-cpp >=1.10.3,<2.0a0",
+    "azure-core-cpp >=1.10.3,<1.11.0a0",


bus about data drill and data linkage

when you first use data drills and then use data linkage,some bugs will appear.The first picture is the correct situation.But when you use data linkage on it,you can see the second picture,some bugs appear,like undefined,and show all data,not drill data.

fixed #1350


implement the trait for more types from the stdlib

Hello,
I found this trait and derive useful, so I added an opt-in feature "std_impls" that can add IsEmpty to more types such as HashMaps and BTreeMap!

@TotalKrill I think that () should implement IsEmpty as always returning true.


Modify Slack Security group to remove Max once he leaves and add Calvin

Right now, Max is part of the Slack Security group and thus gets automatically invited to all incidents. We need to modify the Slack security group so that Max is taken out and Calvin added to it once Max leaves.

Max is out, Calvin is In


Use a single location to specify the name for link features

Coverage remained the same at 100.0% when pulling 3823860f15e1b6a1660174177daeb88709f8ad20 on hotfix/dynamic_link_naming into 3fbf628902bd95e56ff9eece44f3e15c97790149 on master.

Approved

Approved

Approved

Approved


Fix can't open documents in explorer

Any time you expand a DocumentDB collection, you got an error like this:

It's because this.getPartitionKeyValue() relies on this.data, which wasn't set yet

Added another fix for 'Update to Azure' after switching tabs

textEditors get disposed when the user switches tabs
The onDidCloseTextDocument event also occurs when the user switches tabs
Instead, cache the document, which does not get disposed


Add Truffleruby head to CI

Hi @gogainda
Could you provide more context why this change? Do you use TruffleRuby and knapsack at your workplace?

Hi, we are expanding list of supported gems. Once I checked that gem is supported I add it to the list here https://github.com/eregon/truffleruby-gem-tracker/blob/master/gems.yml which we are using to track any regressions. Any issues related to Truffleruby should be handled by Truffleruby dev team so you shouldn't be worried about it

@gogainda Thanks. Please let me know when you add the knapsack gem to your list.


federation services: known issues

 Issue by nikhiljindal
Monday May 22, 2017 at 19:18 GMT
Originally opened as https://github.com/kubernetes/kubernetes/issues/46240

Documenting the list of known issues with federated services:

[ ] Should configure CNAME records instead of A records on AWS: https://github.com/kubernetes/kubernetes/issues/35637
[ ] Duplicate resource record errors with Route53: https://github.com/kubernetes/kubernetes/issues/42131
[ ] Remove DNS entries when a cluster is removed from federation: https://github.com/kubernetes/kubernetes/issues/36657
[ ] Fail to create DNS records for multizone clusters: https://github.com/kubernetes/kubernetes/issues/35997

cc @kubernetes/sig-federation-bugs @shashidharatd @madhusudancs

 Comment by madhusudancs
Monday May 22, 2017 at 19:42 GMT

Should configure CNAME records instead of A records on AWS: #35637

Can we please characterize the first issue correctly? We already know that's not even the right solution. I would characterize it along the lines of "Ensure that resolved IP addresses don't go out of sync with the ELBs on AWS" or something like that? I think the linked issue also does a good job of explaining the issue.

 Comment by quinton-hoole
Saturday Sep 02, 2017 at 00:46 GMT

Added priority.  Need to fix this before Federation GA.

cc @nikhiljindal

@madhusudancs I just re-read your comments on the AWS DNS issue. After having experimented for awhile, it seems to me that we should not sweep under the carpet the fact that we effectively want to dns-load-balance multiple DNS endpoints (one for every cluster for every federated service).
Let's have the following:
Let's say we have a federation deployment with the following clusters: aws1, aws2, gcp1, gcp2. Let's say we deploy a federated service named tom. What we effectively want is a DNS endpoint called
service.namespace.federation.svc.my.domain.com

that will "load-balance" fairly between the clusters, i.e. when we call it we want it to somehow split traffic so that each cluster of aws1, aws2, gcp1, gcp2 gets hit by some percentage of traffic (25% or other depending on configs).
If my understanding of the above is correct, that means we effectively need something like this. I am not sure if GCP CloudDNS, CoreDNS (this), etc. have similar functionalities.
Ideally we can have CNAMEs or A records of the form
service.aws1.namespace.federation.svc.my.domain.com
service.aws2.namespace.federation.svc.my.domain.com
service.gcp1.namespace.federation.svc.my.domain.com
service.gcp2.namespace.federation.svc.my.domain.com

And then we can "load-balance" them bu creating an appropriate routing record called
service.namespace.federation.svc.my.domain.com

which will represent the service and will load-balance between the 4 endpoints above.
What do you think? @madhusudancs


Support CentOS / Redhat + FIX tests

FIX unit tests and acceptance test
Add supported OS in metadata file
Add travis configuration for Continuous Integration
Support Centos / Redhat

lgtm

What is "lgtm"?

looks good to me

:+1:

Released on Forge as 1.7.0, thanks!
https://forge.puppet.com/hubspot/nexus/readme


test: restore e2e tests after updating modules

What type of PR is this?

/kind test
What this PR does / why we need it:
This PR restores the e2e tests of Kusion CLI after updating the Kusion modules.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?

Additional documentation e.g., design docs, usage docs, etc.:

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.02%) to 54.852%

Totals

Change from base Build<PHONE_NUMBER>:
0.02%

Covered Lines:
8830

Relevant Lines:
16098

💛  - Coveralls


Let linting exit with a nonzero status

Relates to #206

Looks good to me too!  Thanks again, @courtneypattison.  Merging


[Proposal] Capture coverage information in wasm-pack test

This follows up on my work in: https://github.com/rustwasm/wasm-bindgen/issues/2276
I have a very rough proof of concept and would like to discuss further implementation details before moving towards a PR.
The rough idea

The usual profiler_builtins aren't implemented for wasm, so we need to use minicov
We want to issue a call to minicov::capture_coverage after the run of every test

The data can be dumped across as many files as we like, so we can either dump into a file after every single test, or dump it all at after all tests have run - which would offer more performance

Afterwards the generated .profraw files can be merged into a .profdata
A .profdata can be used to generate an HTML coverage report

Building the code
If minicov is linked, then RUSTFLAGS="-Cinstrument-coverage -Zno-profiler-runtime --emit=llvm-ir" wasm-pack test is sufficient for getting the standard compiled wasm from the called cargo build.
However, wasm-interpreter then runs over the file and tries to fetch all the wbgt_describes. Profiling information is already included in these. I made some attempts at using #[coverage(off)] to avoid the generation of calls to the profiler in these functions but was unsuccessful. We can retry this approach if we have the rest working until then I propose the following workaround:
The workaround
All fields related to profiling use i64. Since the interpreter disallows anything other than i32, we can ignore the i64s if we want to capture coverage (add some flag). Otherwise panic as usual.
This means we add the workaround for the instructions i64 const, i64 store, i64 load and i64 add.
Generating the profraw
Using minicov::capture_coverage works fine for getting the data for a single test. Printing the data to a file however doesn't work from a browser. Since the browser already connects to a small rouille server, I suggest creating two extra endpoints in that server:

/__coverage/append

expects the Vec<u8> generated by minicov in the request body
appends it to a vec coverage
should be called after every test
This just moves around an unecessarily large amount of data. We can simply dump once after all tests have run

/__coverage/dump

expects the Vec<u8> generated by minicov in the request body
simply dumps the coverage to a file
should be called after all tests have run so we only generate a single profraw

The code is pretty straightforward here.
Merging the profraws and generating the HTML
I personally don't think we should be taking care of this. That way it should be possible to merge the coverage of normal #[test] unit tests as well, so that #[wasm_bindgen_test] only needs to be used for code that runs only on wasm. I haven't been able to confirm this yet but I'll be looking into it.
Open questions
Reporting the coverage to the server
The following code works:
wasm_bindgen_test::wasm_bindgen_test_configure!(run_in_browser);

pub fn print_bool(b: bool) -> &'static str {
    if b {
        "It's true"
    } else {
        "It's false"
    }
}

#[cfg(test)]
mod test {
    use super::*;

    #[wasm_bindgen_test::wasm_bindgen_test]
    async fn test_foo() {
        // assert_eq!(print_bool(true), "It's true");
        assert_eq!(print_bool(false), "It's false");
        let mut coverage = Vec::new();
        unsafe {
            minicov::capture_coverage(&mut coverage).unwrap();
        }
        let client = reqwest::Client::new();
        client
            .post("http://<IP_ADDRESS>:8000/__coverage/append")
            .body(coverage)
            .send()
            .await
            .expect("Error in append");

        // This shouldn't be done here but in the generated JS code of the test runner
        // after all tests have run
        client
            .post("http://<IP_ADDRESS>:8000/__coverage/dump")
            .send()
            .await
            .expect("Failed dump");
    }
}

Ideally, everything from the line with let mut coverage... would be handled automatically. I tried adding all of it to Context::execute but for some reason when I remove the code from the test itself I get the error:
TypeError: The specifier “env” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”.
The line causing the issue is immediately the first line of the generated JS file:
import * as __wbg_star0 from 'env';
The final dump can probably just be called with fetch from the test harness once all tests have completed.
Retrieving the server URL
We only know that the port is 8000 when running non-headless. In other cases we need to retrieve it and add it to the code here. This is probably easier if we do all the HTTP requests from the runner itself instead of from expanded tests, since the runner knows the server URL.
Gating coverage execution
Wanting to collect coverage now changes code in following places:

The interpreter
The server
The proc macro
The test runner

The server doesn't really matter since the endpoints will never be called.
The interpreter will need some sort of flag to inform it that it shouldn't ignore the i64s it comes across. We can probably just add that as a top level CLI argument.
Same as above for the runner.
The proc macro is the most difficult, if we can move all of the responsibility to the runner, then we have nothing to worry about. If some logic dependent on whether we want coverage or not remains in the expanded code then we will probably have to set an environment variable from the CLI tool to generate the correct code which is pretty ugly.

You can find my changes to this repo here: https://github.com/aDogCalledSpot/wasm-bindgen/tree/coverage

Pinging @daxpedda

Yo, exciting stuff! Is this already in a state where I can try it out?

Not yet, the questions covered really stop this from being viable until they're resolved. I'll open a PR once it's in a more testable state.

All fields related to profiling use i64. Since the interpreter disallows anything other than i32, we can ignore the i64s if we want to capture coverage (add some flag). Otherwise panic as usual.

Would really like to figure out why #[coverage(off)] doesn't work. I don't know enough about this part of wasm-bindgen to say for sure this won't cause problems in the future, but considering this will be an unstable feature it's fine.

Reporting the coverage to the server
The following code works:

As you said: most of this should be moved to the runner. I don't think we need to use an "append" endpoint at all, we can just collect all this data in the runner and when it's done send it to the server.

This looks good, I'm unsure how we will exactly expose it. Passing an experimental flag to wasm-bindgen-test-runner is probably what we want here. It would also be good to figure out exactly how and what error message to print when the right RUSTFLAGS were not supplied.
A good entry in the wasm-bindgen book will also be essential.
Thank you for doing this. Looking forward to the PR!

Would really like to figure out why #[coverage(off)] doesn't work. I don't know enough about this part of wasm-bindgen to say for sure this won't cause problems in the future, but considering this will be an unstable feature it's fine.

I'll document what I've tried and what I found (and how I found what I found) thoroughly in a separate issue and link TODOS in the code to the issue so that it can easily be picked up again. The issue could be as simple as that I didn't add the annotation in enough places but it  could also be more complicated.

As you said: most of this should be moved to the runner. I don't think we need to use an "append" endpoint at all, we can just collect all this data in the runner and when it's done send it to the server.

Agreed, I've updated the proposal.

It's now working in chrome and firefox in both headless and not headless and node. I'm not sure how to invoke Deno as the runner but the code is the same as for node.

Passing an experimental flag to wasm-bindgen-test-runner is probably what we want here

Does --coverage and have it print a warning that this is highly experimental sound okay?
I would suggest an additional --profraw-out so a user can supply a path of where to dump the  generated data. Default is just the current working directory and the name is the name of the tempdir.profraw.
Will also add an experimental feature for coverage to wasm-bindgen-test, which you will have to opt into to make the calls to minicov. Then we can also add a check for that in the runner - if the function isn't found then the user didn't opt in on the cargo level.
Correct RUSTFLAGS, opt-in in the CLI and opt-in in the Cargo.toml should be sufficient for confirming that someone wants to try this.

A good entry in the wasm-bindgen book will also be essential.

Definitely. Near impossible to use otherwise :sweat_smile:

Verifying the RUSTFLAGS on every run seems a bit excessive.If we are already printing a warning about using the coverage feature we could simply print a hint linking to the docs I'm going to add for in case they run into trouble. And the docs can say that if their case isn't covered they should open an issue here.

Does --coverage and have it print a warning that this is highly experimental sound okay?

Call it --experimental-coverage, no need to print anything, it should be described in --help anyway.

I would suggest an additional --profraw-out so a user can supply a path of where to dump the generated data.

Sounds good!

Will also add an experimental feature for coverage to wasm-bindgen-test, which you will have to opt into to make the calls to minicov.

The flag has to be added in wasm-bindgen-test-runner, which is the application called when running cargo test (or wasm-pack test for that matter (I assume)). So it would work like cargo test -- --experimental-coverage. I think this is the only place where the user hooks in, or what am I missing?

Verifying the RUSTFLAGS on every run seems a bit excessive.

Not sure what you mean, but I originally meant to make sure that users set the right RUSTFLAGS because otherwise they will get some pretty esoteric error messages I assume. So we could just help out with that. In any case, it's just a bonus.

The flag has to be added in wasm-bindgen-test-runner, which is the application called when running cargo test (or wasm-pack test for that matter (I assume)). So it would work like cargo test -- --experimental-coverage. I think this is the only place where the user hooks in, or what am I missing?

The test runner currently gets all its arguments via environment variables, so I would just follow suit there and add take care of handling the command line args in wasm-pack.
So wasm-pack test --experimental-coverage automatically sets WASM_BINDGEN_TEST_COVERAGE=1 and then wasm-bindgen-test-runner will read that env var again.

The test runner currently gets all its arguments via environment variables, so I would just follow suit there and add take care of handling the command line args in wasm-pack.

The wasm-bindgen-test-runner has to also parse arguments passed to it from cargo test.
Which you can see handled here: https://github.com/rustwasm/wasm-bindgen/blob/adcf7786d14943244cbe418a2a17d00430008e2e/crates/test/src/rt/mod.rs#L295-L314
And passed from here:
https://github.com/rustwasm/wasm-bindgen/blob/adcf7786d14943244cbe418a2a17d00430008e2e/crates/cli/src/bin/wasm-bindgen-test-runner/main.rs#L198-L215
So cargo test -- --experimental-coverage should show up there. I know very little of wasm-pack, but I would assume wasm-pack test -- --experimental-coverage should be passed along correctly as well?
In any case, now that I think about it maybe we should use an environmental variable anyway and stick with only supporting the same args as the native Cargo test runner.
Ideally in the future, we would figure out a way if coverage is enabled or not without any environment variable or flag at all. Not sure if there is currently a way to do this at all.
Apologies btw, I don't have anything to do with wasm-pack so I'm only talking from wasm-bindgens perspective here!

I originally meant to make sure that users set the right RUSTFLAGS because otherwise they will get some pretty esoteric error messages I assume

Yeah, you simply wouldn't find any coverage data. I'm personally not a fan of going through all the RUSTFLAGS though. If someone were to not use wasm-pack test and manually cargo build and cargo test then the RUSTFLAGS wouldn't have to be set.

I think I have expressed myself very poorly here. What I meant to say is that we should check what happens if users enable coverage but don't pass the right RUSTFLAGS. If this causes really esoteric error messages that are impossible to debug, it would be nice if we could somehow detect that and tell the user whats wrong.
How we would do that I have no clue, so if you have any ideas it would be nice to discuss that.
If all that happens is that there is no coverage data, then that's ideal, no need to do anything here!
But again: this is probably something we can leave for a follow-up.

The wasm-bindgen-test-runner has to also parse arguments passed to it from cargo test.
Which you can see handled here:

The line is commented with
https://github.com/rustwasm/wasm-bindgen/blob/adcf7786d14943244cbe418a2a17d00430008e2e/crates/test/src/rt/mod.rs#L293-L294
and is followed by
https://github.com/rustwasm/wasm-bindgen/blob/adcf7786d14943244cbe418a2a17d00430008e2e/crates/test/src/rt/mod.rs#L296-L300
and the test-runner main also says:
https://github.com/rustwasm/wasm-bindgen/blob/adcf7786d14943244cbe418a2a17d00430008e2e/crates/cli/src/bin/wasm-bindgen-test-runner/main.rs#L51-L52
So I think it's best to leave it as an environment variable for now.

Apologies btw, I don't have anything to do with wasm-pack so I'm only talking from wasm-bindgens perspective here!

That's fine. The wasm-pack changes are just parsing a flag. Everything else depends on what happens in wasm-bindgen the interface correct here is the most important - regardless of wasm-pack.

Ideally in the future, we would figure out a way if coverage is enabled or not without any environment variable or flag at all. Not sure if there is currently a way to do this at all.

Ideally the profiler is built into the .wasm and is supported by LLVM. Then you could just use grcov to take care of everything since executing the file will simply passively generate .profraw files. (Ideally llvm-cov would also be able to parse the DWARF info out of the .wasm since it's actually in there saving us yet another step).

What I meant to say is that we should check what happens if users enable coverage but don't pass the right RUSTFLAGS. If this causes really esoteric error messages that are impossible to debug, it would be nice if we could somehow detect that and tell the user whats wrong.

I understood that. I guess I'm the one who's being cryptic.
Conveniently or infuriatingly, depending on how you want to look at it, you don't really get much output at all when trying to generate coverage data. If you have all the stuff in wasm-bindgen set up correctly but only forget to compile with the correct RUSTFLAGS then minicov won't find any profiling data and won't write anything to the coverage array. This empty array will then be saved as an empty profraw. From there you can actually continue to process this empty file all the way until you have HTML that tells you nothing :laughing: I guess we can add a warning if we're dumping an empty file since this is probably not the user's intention.

The wasm-bindgen-test-runner has to also parse arguments passed to it from cargo test.
Which you can see handled here:

The line is commented with
https://github.com/rustwasm/wasm-bindgen/blob/adcf7786d14943244cbe418a2a17d00430008e2e/crates/test/src/rt/mod.rs#L293-L294

These comments are unfortunately outdated, we have since then already started supporting some flags. E.g. --include ignored.

So I think it's best to leave it as an environment variable for now.

Indeed we should still stick with an environment variable here to stick with the same CLI as the native Cargo test runner. That is until https://github.com/rust-lang/rfcs/pull/3287 is implemented.

From there you can actually continue to process this empty file all the way until you have HTML that tells you nothing 😆 I guess we can add a warning if we're dumping an empty file since this is probably not the user's intention.

I see! Yeah that honestly sounds fine to me, I will leave if you want to add a warning here or not to you.

So there are three things the user has to get right:

RUSTFLAGS need to be set correctly when building in order to generate profiling information (profiling)
WASM_BINDGEN_TEST_COVERAGE environment variable needs to be set (flag)
coverage feature in wasm_bindgen_test needs to enabled (feature)

Here's the output of all the ways you can mix these up:
No profiling, no feature, no flag:
Fine, just as before
No profiling, no feature, flag:
Prints error saying that coverage was supposed to be dumped but feature disabled
No profiling, feature, no flag:
Fine, just as before. Note that you might have issues if you have a crate depending on wasm-bindgen-test that also has minicov as a dependency since you'll have multiple definitions of functions. This is why we have the feature.
No profiling, feature, flag:
Prints error saying that empty coverage data was received. Says what RUSTFLAGS to use (I wanted to have this as a warning but warnings don't seem to be forwarded to the command line in headless mode)
Profiling, no feature, no flag:
wasm-bindgen-interpreter will panic. Prints a hint. (*)
Profiling, no feature, flag:
TypeError: The specifier "env" was a bare specifier
(The JS interpreter can't find the calls to the profiling information)(**)
Profiling, feature, no flag:
wasm-bindgen-interpreter (somewhere else for some reason). Prints a hint.(**)
Profiling, feature, flag:
You get coverage!
(*) If we don't need the workaround in the interpreter, I'm pretty sure this would just take longer to compile but run fine
(**) A better message here would be great but I don't know how to detect this since the problem occurs at link time but it is only printed at runtime.
(*) If we don't need the workaround in the interpreter, this would probably lead to the same linkage error as in ().

Thank you for putting this together!
Hopefully we can figure out a way to address the last three cases somehow in the implementation.

@egasimus PR is open at https://github.com/rustwasm/wasm-bindgen/pull/3782

Try this:
[dev-dependencies]
wasm-bindgen-test = { version = "0.3", features = ["coverage"] }

[patch.crates-io]
wasm-bindgen-test = { git = "https://github.com/aDogCalledSpot/wasm-bindgen", branch = "coverage" }
wasm-bindgen = { git = "https://github.com/aDogCalledSpot/wasm-bindgen", branch = "coverage" }
wasm-bindgen-shared = { git = "https://github.com/aDogCalledSpot/wasm-bindgen", branch = "coverage" }


Save files versioning

I was thinking to start versioning our save files as the app may face changes to the save formats as we add features. By doing so we would then be able to properly convert users data without losing any chat or settings with updates

I agree otherwise you may run into issues after upgrading the app.
I would do the following.

Write the sessions to json files instead of storing them into a Hive DB.
Write them into the "applications data" folder instead of the users "documents" folder
Add a version number to the json files so we can upgrade them later if we have structural changes.

Technically speaking we're already using the JSON format under the hood with Hive, as you can see ChatSessionWrapper is in fact a JSON convertible. We can just add a metadata object that would contain the 'version' field and some along with some other infos allowing us to achieve the same result but keeping users data protected as Hive provides a basic form of encryption by default (we might even upgrade to something like sha-256 in the future). Coming to the second point, I strongly agree with you, we must move sessions to the app data folder.


Test suite produces warnings

I noticed that after merging #25 there are some tests that produce warnings. By looking at the whole test suite closed I noticed that abstract classes are being used in tests which I think makes the test suite hard to understand. It also causes some tests cases not being executed, more particularly the ones that use @dataProvider.
I'd like to propose to refactor the test suite so that abstract classes are not used anymore. This however means that we have duplicate code (copy all test cases into each adapters test class) or use a test method per adapter type and move real assertions to protected methods.
@NoelDavies whats you view on this? I'm happy to submit a example PR if that would help.

That'd be brilliant. I didn't notice them. Good spot

@NoelDavies check out #27 would you be ok with such approach?

I'm wondering whats the idea behind BlackBoxTest, and why does it increment metrics 1100 times?

@NoelDavies I closed the initial PR and opened a new one - #27, it turned out the issue was in PHPUnit bug that got fixed in latest release.

I added a review. Once those are looked at we'll push up :D


[EventRequest] Table 246 "Requisition Line"

Hello MS,
Please help us in migrating our verticalized solution by adding below events to function ValidateLocationChange in "Requisition Line" table.
Version (BC17 Cu03). Requested event OnValidateLocationChange
local procedure ValidateLocationChange()
var
    Purchasing: Record Purchasing;
    SalesOrderLine: Record "Sales Line";
begin
    case true of
        "Location Code" = xRec."Location Code":
            exit;
        "Purchasing Code" = '':
            exit;
        not Purchasing.Get("Purchasing Code"):
            exit;
        not Purchasing."Special Order":
            exit;
        not SalesOrderLine.Get(SalesOrderLine."Document Type"::Order, "Sales Order No.", "Sales Order Line No."):
            exit;
        "Location Code" = SalesOrderLine."Location Code":
            exit;
        OnValidateLocationChange(Rec,IsHandled);
    end;

    Error(Text028, FieldCaption("Location Code"), TableCaption);
end;

[IntegrationEvent(false, false)]
local procedure OnValidateLocationChange(var RequisitionLine: Record "Requisition Line"; var IsHandled: Boolean)
begin
end;

Please always put the full detailed signature of the requested events.
You help us implementing the requests faster when your request contains AL code copied from VSCode instead of screenshots.
Please put the code surrounding the place, where you expect a new event call, as a text not as a screenshot.
It helps us finding the right place quickly if you put enough code to identify the unique place.

Please always put the full detailed signature of the requested events.
You help us implementing the requests faster when your request contains AL code copied from VSCode instead of screenshots.
Please put the code surrounding the place, where you expect a new event call, as a text not as a screenshot.
It helps us finding the right place quickly if you put enough code to identify the unique place.

Done.


Duplicate murderer messages

Sometimes, the murderer message is displayed multiple times per round even though it is only supposed to show once.

Fixed in da342fdbe95aa6c86c602934b7c68e32b52c0478.


Change patron to typheous [WIP]

Codecov Report

Merging #6 into master will increase coverage by 0.13%.
The diff coverage is 54.54%.

@@            Coverage Diff             @@
##           master       #6      +/-   ##
==========================================
+ Coverage   34.69%   34.83%   +0.13%
==========================================
  Files          65       65
  Lines        3006     3003       -3
==========================================
+ Hits         1043     1046       +3
+ Misses       1963     1957       -6

Impacted Files
Coverage Δ

lib/zold/http.rb
59.61% <54.54%> (+8.7%)
:arrow_up:

Continue to review full report at Codecov.

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


update latest index page for zh-tw

as title
cc @lunny

Trusted LGTM

LGTM

Please send also to release/v1.0.


Missing byteswap.h on MSVC and macOS

On MSVC and macOS I get build errors due to missing include byteswap.h, i.e.
C:\builds\taopq\include\tao/pq/internal/parameter_binary_traits.hpp(13): fatal error C1083: Cannot open include file: 'byteswap.h': No such file or directory

The docs only mention this header on glibc systems. Should I look for a drop-in replacement for other platforms?

On macOS perhaps machine/endian.h or libkern/OSByteOrder.h could be used instead. We also have endian.hpp in the PEGTL which seems to work everywhere.

I'll take care of it as soon as I find some time.

Thanks @d-frey !

Should be fixed now.

Thanks, I confirm this works on macOS and MSVC!


CSS

CSS
User Story
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
Acceptance Criteria
GIVEN a Prework Study Guide website
WHEN I view the study guide
THEN I see a dark blue header and footer, and four boxes with a shadow

added CSS HTML info & external CSS style sheet


Updating code for distribution and maximizing physical space

This issue is designed to recapitulate previous changes to the code base.  This issue details version 1.2 of the experimental generator code with the intention of outlining known bugs with the code that exist in the 1.2 version of the software.

Need to create a centralized source of information on this code and make it ready for broader distribution.  This is in line with the recent goals of improving documentation prior to forking to the DRP project.

This issue has been fixed.  Code updated and able to sample the limits of concentration for the inorganic and organic reagents.


Remove quotation marks from "text-based content that is not a question"

Current behavior

@hickman-santini where does this happen?

 Well this is typically the kind of thing where you can make a PR with github's dev feature if you have the time.


lite: fix build error

Motivation for this change
ZHF: #122042
cc @NixOS/nixos-release-managers
Things done

[X] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
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 nixpkgs-review --run "nixpkgs-review wip"
[X] Tested execution of all binary files (usually in ./result/bin/)
[ ] Added a release notes entry if the change is major or breaking
[X] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 124046 at 8780e8dd run on x86_64-linux 1

1 package built successfully:

lite

2 suggestions:

warning: missing-phase-hooks
installPhase should probably contain runHook preInstall and runHook postInstall.
Near pkgs/applications/editors/lite/default.nix:45:3:
   |
45 |   installPhase = ''
   |   ^

warning: missing-phase-hooks
buildPhase should probably contain runHook preBuild and runHook postBuild.
Near pkgs/applications/editors/lite/default.nix:34:3:
   |
34 |   buildPhase = ''
   |   ^

nixpkgs-review happy for me, macos 10.15, nixos x86_64


Avoid sending the remove request with empty objects

https://github.com/longhorn/longhorn/issues/774

In fact it's for https://github.com/longhorn/longhorn/issues/768


add dev options for golang-builder job

doozer fails currently when you build --scratch but that can be solved separately


Please update the supported OS versions in the main README file for the repo

In the https://github.com/SAP/macOS-enterprise-privileges/blob/main/README.md file, the supported OS versions are listed as follows:
Privileges supports the following macOS versions:

macOS 15.x
macOS 14.x
macOS 13.x
macOS 12.x
macOS 11.x

Privileges 2.x appears to support the following OS versions:
macOS 15.x
macOS 14.x
macOS 13.x

Can the supported OS versions listed in the https://github.com/SAP/macOS-enterprise-privileges/blob/main/README.md file please be  updated to match the OS versions supported by Privileges 2.x?

@rtrouton Privileges 2 runs on macOS 11 and higher, so the information in the README.md file seems to be correct.

OK, thank you. I hadn't tested this, so I was going by what was listed on the release page.

Changed the release page accordingly. Thanks for reporting this.


Support Python 3.5.0

Cookiecutter should support Python 3.5.0 (jippiie). I created a branch with the neccessary changes:
https://github.com/maiksensi/cookiecutter/tree/feat/support-for-py35
It already works with appveyor, as they recently updated their installations. Regarding Travis-CI, there is an open ticket at travis-ci/travis-ci#4794. There is a workaround but I guess it is not worth it. Instead, I will update this ticket as soon as they install py35 and create a PR.

Please see #522


Modify StaticResources Cache-Control header, to allow caching large files.

To minimize clients downloading large static css/js files.

Shall we do compression whilst here? Should be straight forward but I don't have much experience as to whether its a good idea or not

This is great, I'm seeing load times reduce form ~10s to < 2s 👍

Compression yes! If the request headers indicate the client supports gzip, we should compress the response, that will make a big difference to decrease initial page load time. Unfortunately I don't know scala/http4s and had no luck finding an example to follow.

No worries, I can have a go at that. Thanks for the PR!

Just thinking, shouldn't we use etags here?

Gzip added in #71

Thanks Toby for adding Gzip!
When I worked on web projects 10 years ago, I targeted the simplest
solution for the majority of browsers, i.e. simple cache control headers
for static files. However, today all browsers should correctly support
etags. If it only requires enabling a feature in the http server to
generate and honor etags, I don't see why not. :)
Matt
-- Matt
On Tue, May 15, 2018 at 10:44 AM, Toby<EMAIL_ADDRESS>wrote:

Gzip added in #71
https://github.com/tobyweston/temperature-machine/issues/71
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/tobyweston/temperature-machine/pull/61#issuecomment-389234794,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AjEUZRp-18cGAaXQR46ISehP4P_U9lV4ks5tywYFgaJpZM4SW7x8
.


I have no idea what you're talking about. I need some more context here.

I will send a screenshot

Looks like a chapter has no valid url. The log/ terminal should have more info.


[V4] custom jest transforms (e.g. ts-jest) no longer working

Tried out 4.0.0-next.98 today (coming from 3.4.3) in a medium-sized typescript monorepo. Our app builds and runs just fine.
Unfortunately some of our Jest tests broke. It looks like ts-jest is no longer getting used. Previously (with CRA3) we were able to specify a transform in the jest section of package.json like this:
    "transform": {
      "^.+\\.(js|jsx|ts|tsx)$": "<rootDir>/node_modules/ts-jest"
    },

This allowed us to use TypeScript features not supported by Babel (like emitDecoratorMetadata for TypeORM).
Looking at the v3.4.1...master diff, I'm not sure what broke it. Perhaps something about Jest 26?
I will try to produce a repro repo when I can.
Repro steps in short:

npx create-react-app --template typescript my-react-app
add a const enum to the test (not supported by babel)
yarn test (see it fail)
install ts-jest and add the transform line above
yarn test (see it pass)
update to react-scripts 4.0.0-next.98, see yarn test break again.

Example repo here: https://github.com/jrr/cra-4-ts-jest-issue

I tried this today with the 4.0 release and it's still broken. Repro repo updated:
https://github.com/jrr/cra-4-ts-jest-issue

I'm on the same project as @jrr and I discovered that passing in the transform property as a CLI argument can be used as a workaround

Changing the transform key to match the regex in createJestConfig for babel-jest fixes this.
I.E change:
"transform": {
  "^.+\\.(js|jsx|ts|tsx)$": "<rootDir>/node_modules/ts-jest"
},

to
"transform": {
  "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$": "ts-jest"
},

I bet it was this PR, which changed the regex between CRA 3 and 4:
https://github.com/facebook/create-react-app/pull/8768/files
The overridden transform object is merged with CRA's default:
https://github.com/facebook/create-react-app/blob/027b03ba8d689e619a912ed0d72c3a11ef22ac2f/packages/react-scripts/scripts/utils/createJestConfig.js#L97-L107
So, practically, this means you can change the transform applied to CRA's regex, but you can't change the regex.
It also means your config override can silently break if upstream's regex changes. 😐

Closing as its no longer affecting us. To anyone stumbling upon the thread: if you're using the "jest" configuration key in package.json, dig in to react-script's source to understand what it's doing, and don't be surprised if your configuration breaks during upgrades.

I've been trying to get this to work for 2 days but found no success yet.
I have this property in package.json
 "jest": {
    "transform": {
      "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$": "ts-jest"
    }
  }

With package versions:
"react-scripts": "4.0.3",
"ts-jest": "^26.5.2",

The key  "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$" matches the one in createJestConfig.js for these versions, but it still doesn't work.
My script for testing in package.json is:
"test": "react-scripts test"

What am I doing wrong?

I've been trying to get this to work for 2 days but found no success yet.
I have this property in package.json
 "jest": {
    "transform": {
      "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$": "ts-jest"
    }
  }

With package versions:
"react-scripts": "4.0.3",
"ts-jest": "^26.5.2",

The key  "^.+\\.(js|jsx|mjs|cjs|ts|tsx)$" matches the one in createJestConfig.js for these versions, but it still doesn't work.
My script for testing in package.json is:
"test": "react-scripts test"

What am I doing wrong?

I think I figured it out. It seems the transform property was not at fault actually and that my error was somewhere else. I set "resetMocks": false, in my jest configuration in package.json and this solved my problem.
I was getting some cryptic error messages, that's why I couldn't identify the root cause accurately. It seems that since v4 of react-scripts, the resetMocks flag is set to true by default, which is different behaviour than in the previous version.


Redesign: Update video captions panel

Feature Description
See Figma

[ ] Title
[ ] Input
[ ] Fieldset

Additional Context

Do not alter or remove anything below. The following sections will be managed by moderators only.
Acceptance Criteria

Implementation Brief

Verified in QA


Add payment method withdrawal functionality

This adds the ability to withdraw to a payment method -- a complement to the recent https://github.com/coinbase/gdax-node/pull/314

Edit by @rmm5t:

Closes #30

Thanks a lot!


init.py:1: Implement Page context class.

The puzzle 207-f1b71ce7 from #207 has to be resolved:
https://github.com/fidals/refarm-site/blob/11231f5a529b4ac59cb90239b6bc86e01e5957d2/catalog/newcontext/__init__.py#L1-L1
The puzzle was created by Artemiy on 31-Dec-18.
If you have any technical questions, don't ask me, submit new tickets instead. The task will be "done" when the problem is fixed and the text of the puzzle is removed from the source code. Here is more about PDD and about me.

@0pdd 3 puzzles #267, #268, #269 are still not solved.

@0pdd 2 puzzles #268, #269 are still not solved; solved: #267.

@0pdd the puzzle #269 is still not solved; solved: #267, #268.


Make an option to put a LACT indicator in the menu bar, to make visible that the daemon is still running in the background

I understand that technically this is not needed, but it is nice to have explicit confirmation.

This isn't really possible as is, since the daemon runs as root without being bound to a graphical session. It would need to be a separate process just for the tray icon, which I think would be overkill (and this process could exit without the actual daemon exiting).

Ah, good point. Thanks for the consideration!


KAFKA-8240: Fix NPE in Source.equals()

More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Call for review @guozhangwang @bbejeck @vvcephei @ableegoldman @cadonna

Java8 failed with know flaky test. Java11 passed.
Retest this please.

Java 8 passed, Java 11 failed; test results already cleaned up
retest this please

Failed with Execution failed for task ':core:compileTestScala'. but a PR (#6603) has been merged for this.
retest this please

Rebased.

Updated this.

@bbejeck @vvcephei @cadonna Build finally passed. I change couple of things. Would like to get another review to make sure it's still ok.

Updated this.

Updated this.

LGTM

Merged #6589 to trunk


Add OpenLiberty MicroProfile TCK to external test

Signed-off-by: Mesbah<EMAIL_ADDRESS>

Testing this PR: https://ci.adoptopenjdk.net/view/work in progress/job/TestBuild_Sandbox2/375/testReport/


Update installation.rst to add swig for WSL

swig is needed for installation by default which is included in Ubuntu installation description but not the WSL

thanks


begin_analyze_document_from_url does not exist...

In this "doc_intel_quickstart.py" sample application the function being called "begin_analyze_document_from_url" does not exist  in "DocumentIntelligenceClient".
I get the following error:
[2024-02-03 01:49:51 +0000] [29] [ERROR] Exception in ASGI application
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/uvicorn/protocols/http/httptools_impl.py", line 419, in run_asgi
result = await app(  # type: ignore[func-returns-value]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/uvicorn/middleware/proxy_headers.py", line 84, in call
return await self.app(scope, receive, send)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/fastapi/applications.py", line 1054, in call
await super().call(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/applications.py", line 119, in call
await self.middleware_stack(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/errors.py", line 186, in call
raise exc
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/errors.py", line 164, in call
await self.app(scope, receive, _send)
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/cors.py", line 83, in call
await self.app(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/middleware/exceptions.py", line 62, in call
await wrap_app_handling_exceptions(self.app, conn)(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/_exception_handler.py", line 64, in wrapped_app
raise exc
File "/usr/local/lib/python3.11/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
await app(scope, receive, sender)
File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 762, in call
await self.middleware_stack(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 782, in app
await route.handle(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 297, in handle
await self.app(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 77, in app
await wrap_app_handling_exceptions(app, request)(scope, receive, send)
File "/usr/local/lib/python3.11/site-packages/starlette/_exception_handler.py", line 64, in wrapped_app
raise exc
File "/usr/local/lib/python3.11/site-packages/starlette/_exception_handler.py", line 53, in wrapped_app
await app(scope, receive, sender)
File "/usr/local/lib/python3.11/site-packages/starlette/routing.py", line 72, in app
response = await func(request)
^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/fastapi/routing.py", line 299, in app
raise e
File "/usr/local/lib/python3.11/site-packages/fastapi/routing.py", line 294, in app
raw_response = await run_endpoint_function(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/fastapi/routing.py", line 191, in run_endpoint_function
return await dependant.call(**values)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/main.py", line 429, in analyze_document
poller = document_intelligence_client.begin_analyze_document_from_url(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'DocumentIntelligenceClient' object has no attribute 'begin_analyze_document_from_url'

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

ID: ff1757f1-3eb4-923b-7904-1c6369e7ba0b
Version Independent ID: d0f9e299-8553-30b5-1bf0-8f454925584e
Content: Quickstart: Document Intelligence (formerly Form Recognizer) SDKs - Azure AI services
Content Source: articles/ai-services/document-intelligence/quickstarts/get-started-sdks-rest-api.md
Service: azure-ai-document-intelligence
GitHub Login: @laujan
Microsoft Alias: lajanuar

@bahar-wmmls
Thanks for your feedback! We will investigate and update as appropriate.

Hello any updates on this issue? I have the same problem. Thanks

@bahar-wmmls Thanks for your feedback! We will investigate and update as appropriate.

Isn’t having accurate documentation about improving your docs?BaharSent from my iPhoneOn Feb 6, 2024, at 6:55 AM, RamanathanChinnappan @.***> wrote:
@bahar-wmmls
Since this issue isn't directly related to improving our docs, and to gain a better understanding of your issue, I'd recommend working closer with our support team via an [Azure support request] (https://docs.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request). Or you can leverage our Q&A forum by posting your issue there so our community, and MVPs can further assist you in troubleshooting this issue or finding potential workarounds.
[Teams Q&A forum] (https://docs.microsoft.com/en-us/answers/topics/46488/office-teams-windows-itpro.html) for technical questions about the configuration and administration of Microsoft Teams on Windows.
[Microsoft Teams Community forum] (https://answers.microsoft.com/en-us/msteams/forum?sort=LastReplyDate&dir=Desc&tab=All&status=all&mod=&modAge=&advFil=&postedAfter=&postedBefore=&threadType=All&isFilterExpanded=false&page=1
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>


Jsonnet-base pipeline templates

This PR adds support for jsonnet-based pipeline templates. For context, and the design, see https://docs.google.com/document/d/1VC8SY2hmf5BQShJSmUvQ_q0hXV6ErRl25BmgK1f_KtI/edit

This PR has been replaced with https://github.com/pachyderm/pachyderm/pull/6930


The CSV files are missing geo subjects returned by the MMDB

Problem
I've downloaded the latest updates of the Maxmind's GeoLite2 City database (both in MaxMind DB binary and CSV formats). When I tried to look up "<IP_ADDRESS>" here's what I got:
{"city":{"geoname_id":2982652,"names":{"de":"Rouen","en":"Rouen","es":"Ruan","fr":"Rouen","ja":"ルーアン","pt-BR":"Ruão","ru":"Руан","zh-CN":"鲁昂"}},"continent":{"code":"EU","geoname_id":6255148,"names":{"de":"Europa","en":"Europe","es":"Europa","fr":"Europe","ja":"ヨーロッパ","pt-BR":"Europa","ru":"Европа","zh-CN":"欧洲"}},"country":{"geoname_id":3017382,"is_in_european_union":true,"iso_code":"FR","names":{"de":"Frankreich","en":"France","es":"Francia","fr":"France","ja":"フランス共和国","pt-BR":"França","ru":"Франция","zh-CN":"法国"}},"location":{"accuracy_radius":5,"latitude":49.4431,"longitude":1.0993,"time_zone":"Europe/Paris"},"postal":{"code":"76100"},"registered_country":{"geoname_id":3017382,"is_in_european_union":true,"iso_code":"FR","names":{"de":"Frankreich","en":"France","es":"Francia","fr":"France","ja":"フランス共和国","pt-BR":"França","ru":"Франция","zh-CN":"法国"}},"subdivisions":[{"geoname_id":11071621,"iso_code":"NOR","names":{"de":"Normandie","en":"Normandy","es":"Normandía","fr":"Normandie"}},{"geoname_id":2975248,"iso_code":"76","names":{"de":"Seine-Maritime","en":"Seine-Maritime","es":"Sena Marítimo","fr":"Seine-Maritime","pt-BR":"Sena Marítimo"}}]}

However, there's no corresponding geoname_id for returned subdivisions in CSV files (e.g. cat GeoLite2-City-Locations-en.csv | fgrep 11071621 returns nothing). This situation is very common for subdivisions (e.g. Novosibirsk Oblast, Scotland, etc). Is it a bug or an expected behavoiur? What is the relation between the CSV files and the MMDB format?
Why is it important
For services that employ some kind of targeting or filtering of traffic based on location, the geoname_id's are important. For example, if we have an ad serving network and want to allow users to restrict a particular ad to a set of geolocations, it makes sense to describe such a set using respective geoname_id's from the CSV files and compare against it the geoname_id's returned by the MMDB format when deciding whether or not to serve the ad (depending on from which location the request came from). However, if a geoname_id is absent in the CSV files we can't use restrict the ad to the respective location even though the MMDB format returns it when resolving an IP address.
Workaround
A workaround is to manually add missing objects to the CSV files using the IDs returned by the MMDB format (although there's a lot of them to add manually), but in this case, a very important question is whether these geoname_id's are reliable or are they likely to change in the future?

Each IP in both the CSV and MMDB file will map to exactly one geoname_id, and each of
those geoname_id's will be found in the Locations files.
The subdivisions are values mapped to a particular location, not directly mapped to a
given IP address. We do not include the geoname_id's of subdivisions in the CSV files by
design, only the ISO code and name. If no IP's are mapped directly to a given
subdivision, it is expected that the geoname_id for that subdivision will not appear in
the Locations CSV files.
The geoname_id's are taken directly from https://www.geonames.org/, so you may be able
to look there if there is data that you need which isn't otherwise find the CSV files.

@klp2 Thank you for the clarification! So, if I understand correctly the same logic works for countries (e.g. if we have a country which IP ranges are fully covered by its cities, the country will not be included in the CSV), right?

The subdivisions are values mapped to a particular location
How are the values mapped? Unfortunately, the hierarchy of geo-objects is quite difficult to reproduce from the files that Geonames provide (even the hierarchy.txt is not complete). Is there any chance that this mapping can be extracted from the MaxmindDB? This will at least show what locations are missing in the CSV files.

All of the countries should show up in the Locations files.
I don't think there is a particularly easy way to extract the mapping out of the MMDB files.


added "is not None" to a bunch of stuff

Not sure why Coverage isn't passing again - but all the tests seem to run, both locally and via Travis. Going to Squash and merge.


fix(aur): Use newest xpp commit to build with xcb-proto

Just got back from vacation and see that the new xcb-proto version breaks all
builds in the AUR. This is only a temporary fix until we do a proper release
containing the fix.
Will try to catch up on all the things I missed in the next few days
Fixes #1090

I have gone ahead and already pushed the changes to the AUR repo, as otherwise the polybar package would not ever build.


new module: charts

Dashboards has their own charting tools for dataviz, but I think it would be valuable to implement basic uikit charts for:

pie chart
line chart
bar chart
count (total) chart
sparkline chart

I would be keen to contribute here.

Hey guys, would suggest maybe we can build some uikittehness on top of Google Charts for a quick win here? https://developers.google.com/chart/interactive/docs/gallery/piechart#donut

I totally agree we need this. As this is a big broad I close it for now but please feel free to open a suggestion in the forums here: https://community.service.gov.au/c/gold/suggest-a-component


Weird syntax highlighting

Seems to be triggered by the event keyword?

Very likely. https://github.com/TypeStrong/atom-typescript/issues/675 needs a hero :rose:

Should work with release https://github.com/TypeStrong/atom-typescript/releases/tag/v8.0.0 :rose: If not raise issue at https://github.com/Microsoft/TypeScript-TmLanguage/issues and link us :rose:


[feat] Electron to Tauri

Describe the problem
I am interested in finding a solution for migrating a live application from Electron to Tauri, in order to provide a seamless experience for current users and eliminate the need for manual downloads. Is this something that can be easily achieved?
Describe the solution you'd like
I think Tauri should make the transition from Electron easier for the current applications which uses Electron with auto update.
Alternatives considered
No response
Additional context
This is the auto update package for most of the Electron applications
https://www.electron.build/auto-update.html

This is a really exciting challenge, and I wonder if the initial bottleneck would be the different codesigners...

yea then we can say goodbye to Electron.

I've toyed around a bit with this today here
https://github.com/simonhyll/electron-to-tauri/
And it was surprisingly easy to get it to download a Tauri .msi file. You just have to put a latest.yaml file in the release with the proper values.
Where I'm struggling atm is that it downloads it and offers to update on exit, but when I click ok to install the update, nothing happens. So yea it doesn't work yet, but I can definitely see it downloading the latest version as long as the yaml file is there in the latest release

Some progress on this issue:
On Linux I've verified that AppImage updating works flawlessly if you just set the values in latest-linux.yml correctly! And since .deb packages should really be distributed through some form of PPA where you'd just upload the new version to, I'd say that switching from Electron to Tauri on Linux at least can be considered fully supported and as simple as editing the .yml file 😄
On Windows I'm still struggling getting it to work, in no small part because I'm having issues finding a way to get proper debugging information for the installation process. It's verifying the file is downloaded and everything, it just doesn't want to work. HOWEVER: all the information required to download it manually is available, so in theory making the app update is as simple as writing a tiny Javascript function that downloads and executes the .msi file. I would prefer not having to go that route but it's certainly looking like the best option currently since the updater is being such a b****.
I can't try switching from Electron to Tauri on Mac unfortunately because I do not own a Mac. :\

Here's a snippet I cooked up that's capable of downloading the .msi and executing it. It's a very basic variant without things like checksum checking, but it works.
autoUpdater.on("update-available", (info) => {
  console.log(info);

  const https = require("https");
  const fs = require("fs");
  const { exec } = require("child_process");

  const url =
    "https://github.com/simonhyll/electron-to-tauri/releases/download/v0.11.0/electron-updater-example_0.11.0_x64_en-US.msi";

  const filePath = "installer.msi";
  const file = fs.createWriteStream(filePath);

  const request = https
    .get(url, function (response) {
      if (response.statusCode === 302) {
        // Follow the redirect
        https.get(response.headers.location, function (newResponse) {
          if (newResponse.statusCode !== 200) {
            console.error(
              "Error downloading file: HTTP",
              newResponse.statusCode
            );
            file.close();
            fs.unlinkSync(filePath);
            return;
          }
          newResponse.pipe(file);
        });
      } else if (response.statusCode !== 200) {
        console.error("Error downloading file: HTTP", response.statusCode);
        file.close();
        fs.unlinkSync(filePath);
        return;
      } else {
        response.pipe(file);
      }

      file.on("finish", function () {
        file.close();
        console.log("Download completed.");

        const install = spawn("msiexec", ["/i", `${filePath}`], {
          detached: true,
        });
        install.unref();
        app.exit(0);
      });
    })
    .on("error", function (err) {
      console.error("Error downloading file:", err);
      fs.unlinkSync(filePath);
    });
});

Steps

Build your Tauri app
Take the appropriate latest-*.yml file from your Electron build
Change the filename and version nr
Remove blockMapSize if it's there, you don't need it
Run sha512sum FILE to get the value to put in the sha512 field
Set the release date field

Tauri supported distribution methods and their status:

✅ "deb": Not required for electron-builder since you just upload the updated version to your PPA
✅ "appimage": Works!! Just do the steps above and it will automagically download and install the AppImage
✅ "msi": You'll need a tiny custom javascript function for downloading and running the .msi, but it's a fairly small snippet and it works. You still update the latest.yml file so that the updater can take care of finding whether or not a new version is available.
❓ "app": I don't have a Mac
❓ "dmg": I don't have a Mac

A tauri equivalent of electron-builder would be fantastic and definitely increase adoption.

We may not advertise it well enough, but Tauri had an electron-builder equivalent built-in from the start. To be fair, Tauri doesn't support as many bundle types yes but we're getting there. There's also a modified version of tauri's bundler called cargo-packager which also works for non-Tauri projects.


Design how generated models will be resilient to changes NOT allowed by the Azure Breaking Change rules

See http://aka.ms/AzBreakingChangesPolicy
This issue tracks the design for this feature for .NET models from Cadl inputs.
[Description TBD]

After the model refactor merged, the version-aware model generation will be supported. @chunyu3 will file another issue to track the version-aware model serialize and deserialize for multi-version client SDK.


"Request Error: Error: An unknown error occurred" on requestSubscription method (iOS)

Description
I'm using "react-native-iap": "^11.0.0-rc.7" following version of react-native-iap. While requesting subscription purchase, I'm getting following error on iOS
"Request Error: Error: An unknown error occurred"
Here is the my code for requesting purchase
const purchaseFullApp = async () => {
        try {
            let sku = _GET_SKUS()[0];
            let offerToken: string | undefined = subscriptions[0].subscriptionOfferDetails ? subscriptions[0].subscriptionOfferDetails[0].offerToken : undefined;

            await requestSubscription({
                sku: sku,
                ...(offerToken && {
                    subscriptionOffers: [{ sku: sku, offerToken }],
                }),
            });

        } catch (error) {
            _showConsoleError(error);
        }
    }

I have also wrote the listener for purchase which you can see in below code:
React.useEffect(() => {
        const checkCurrentPurchase = async () => {
            try {
                if (currentPurchase?.productId) {
                    await finishTransaction({
                        purchase: currentPurchase,
                        isConsumable: true,
                    });
                    setAndStoreFullAppPurchase(true);
                    setUserPurchased(true);
                }
            } catch (error) {
                _showConsoleError(`Purchase Error: ${error}`)
            }
        };

        checkCurrentPurchase();
    }, [currentPurchase, finishTransaction]);

Expected Behavior
On calling requestSuscription(), the payment flow will start and on successful purchase of subscription, I should get full access of application
Screenshots

Environment:

react-native-iap: ^11.0.0-rc.7
react-native: 0.69.1
Platforms (iOS, Android, emulator, simulator, device): Iphone X (iOS 16)

To Reproduce
Steps to reproduce the behavior:

First create an empty project
Install the above IAP version
And then try to call requestSubscription() method with your IAP id

@Haseeba393 please use the release version: 12.0.3. The RCs are not stable for production environments. Please reopen if this still happens on the stable release version

I am getting the same error on version 12.8.2

@OmarBasem please open a new ticket with your particular details


Bad .asc signatures for go{1.12.13,1.13.4}.darwin-amd64.tar.gz

What version of Go are you using (go version)?
n/a - this relates to downloading the Darwin release tarballs for 1.12.13 and 1.13.4
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
n/a
What did you do?
As part of our internal mirroring of Go release tarballs, we check the signatures as detailed in https://github.com/golang/go/issues/14739. This process failed for the newly released go1.12.13.darwin-amd64.tar.gz and go1.13.4.darwin-amd64.tar.gz; here's a quick script to reproduce:
#!/bin/bash

set -e

file=$1
gpghome=$(mktemp -d)
trap '[[ -d "$gpghome" ]] && rm -rf "$gpghome"' EXIT

rm -f "$file" "$file.asc"
curl -s --remote-name-all "https://dl.google.com/go/$file"{,.asc}
curl -s 'https://dl.google.com/dl/linux/linux_signing_key.pub' | gpg --homedir "$gpghome" --import
gpg --homedir "$gpghome" --verify "$file.asc" "$file"

(run as bash go-verify go1.13.4.darwin-amd64.tar.gz)
What did you expect to see?
A valid signature when running the above script for go1.12.13.darwin-amd64.tar.gz and go1.13.4.darwin-amd64.tar.gz
Checking the Linux tarballs for 1.12.13 and 1.13.4 both result in good signatures, and the Darwin tarballs for 1.12.12 and 1.13.3 both have good signatures as well; as an example:
$ bash go-verify go1.12.12.darwin-amd64.tar.gz
gpg: keybox '/var/folders/v5/svyb92cj4kl63m9x1l040txc0000gn/T/tmp.WwzhdEphpI/pubring.kbx' created
gpg: /var/folders/v5/svyb92cj4kl63m9x1l040txc0000gn/T/tmp.WwzhdEphpI/trustdb.gpg: trustdb created
gpg: key A040830F7FAC5991: public key "Google, Inc. Linux Package Signing Key<EMAIL_ADDRESS>imported
gpg: key 7721F63BD38B4796: 1 signature not checked due to a missing key
gpg: key 7721F63BD38B4796: public key "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>imported
gpg: Total number processed: 2
gpg:               imported: 2
gpg: no ultimately trusted keys found
gpg: Signature made Thu Oct 17 17:18:54 2019 CDT
gpg:                using RSA key 6494C6D6997C215E
gpg: Good signature from "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: EB4C 1BFD 4F04 2F6D DDCC  EC91 7721 F63B D38B 4796
     Subkey fingerprint: 3E50 F6D3 EC27 8FDE B655  C8CA 6494 C6D6 997C 215E

What did you see instead?
$ bash go-verify go1.13.4.darwin-amd64.tar.gz
gpg: keybox '/var/folders/v5/svyb92cj4kl63m9x1l040txc0000gn/T/tmp.sJJEYaZWG3/pubring.kbx' created
gpg: /var/folders/v5/svyb92cj4kl63m9x1l040txc0000gn/T/tmp.sJJEYaZWG3/trustdb.gpg: trustdb created
gpg: key A040830F7FAC5991: public key "Google, Inc. Linux Package Signing Key<EMAIL_ADDRESS>imported
gpg: key 7721F63BD38B4796: 1 signature not checked due to a missing key
gpg: key 7721F63BD38B4796: public key "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>imported
gpg: Total number processed: 2
gpg:               imported: 2
gpg: no ultimately trusted keys found
gpg: Signature made Thu Oct 31 18:25:48 2019 CDT
gpg:                using RSA key 6494C6D6997C215E
gpg: BAD signature from "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>[unknown]

$ bash go-verify go1.12.13.darwin-amd64.tar.gz
gpg: keybox '/var/folders/v5/svyb92cj4kl63m9x1l040txc0000gn/T/tmp.w2AmgcB3YR/pubring.kbx' created
gpg: /var/folders/v5/svyb92cj4kl63m9x1l040txc0000gn/T/tmp.w2AmgcB3YR/trustdb.gpg: trustdb created
gpg: key A040830F7FAC5991: public key "Google, Inc. Linux Package Signing Key<EMAIL_ADDRESS>imported
gpg: key 7721F63BD38B4796: 1 signature not checked due to a missing key
gpg: key 7721F63BD38B4796: public key "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>imported
gpg: Total number processed: 2
gpg:               imported: 2
gpg: no ultimately trusted keys found
gpg: Signature made Thu Oct 31 18:25:33 2019 CDT
gpg:                using RSA key 6494C6D6997C215E
gpg: BAD signature from "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>[unknown]

We use golang.org/x/crypto/openpgp for checking signatures as part of the mirroring process; it fails with
could not validate signature for go1.12.13.darwin-amd64.tar.gz: openpgp: invalid signature: hash tag doesn't match

CC @andybons

I suspect we're GPG signing before the new Apple notarization instead of after?

@bradfitz ah yep. We are. Will fix.

I think we can just replace the current .asc files with valid ones, there's no need to wait until the next release: nobody should be checking the checksums of the signature files themselves, and we want to issue valid signatures for the current release anyway.

Yeah that was the plan.

Updated the .asc files and ran the test script provided by @jeffreytolar:
$ ./test.sh go1.13.4.darwin-amd64.tar.gz
gpg: keybox '/tmp/tmp.JvdDhLVh2K/pubring.kbx' created
gpg: /tmp/tmp.JvdDhLVh2K/trustdb.gpg: trustdb created
gpg: key A040830F7FAC5991: public key "Google, Inc. Linux Package Signing Key<EMAIL_ADDRESS>imported
gpg: key 7721F63BD38B4796: 1 signature not checked due to a missing key
gpg: key 7721F63BD38B4796: public key "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>imported
gpg: Total number processed: 2
gpg:               imported: 2
gpg: no ultimately trusted keys found
gpg: Signature made Mon 04 Nov 2019 11:16:29 AM EST
gpg:                using RSA key 6494C6D6997C215E
gpg: Good signature from "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: EB4C 1BFD 4F04 2F6D DDCC  EC91 7721 F63B D38B 4796
     Subkey fingerprint: 3E50 F6D3 EC27 8FDE B655  C8CA 6494 C6D6 997C 215E

$ ./test.sh go1.12.13.darwin-amd64.tar.gz
gpg: keybox '/tmp/tmp.fQIGHHlFOi/pubring.kbx' created
gpg: /tmp/tmp.fQIGHHlFOi/trustdb.gpg: trustdb created
gpg: key A040830F7FAC5991: public key "Google, Inc. Linux Package Signing Key<EMAIL_ADDRESS>imported
gpg: key 7721F63BD38B4796: 1 signature not checked due to a missing key
gpg: key 7721F63BD38B4796: public key "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>imported
gpg: Total number processed: 2
gpg:               imported: 2
gpg: no ultimately trusted keys found
gpg: Signature made Mon 04 Nov 2019 11:16:27 AM EST
gpg:                using RSA key 6494C6D6997C215E
gpg: Good signature from "Google Inc. (Linux Packages Signing Authority<EMAIL_ADDRESS>[unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: EB4C 1BFD 4F04 2F6D DDCC  EC91 7721 F63B D38B 4796
     Subkey fingerprint: 3E50 F6D3 EC27 8FDE B655  C8CA 6494 C6D6 997C 215E

Have some work to do to ensure this doesn't happen again. Working on that now, but closing since this specific issue has been resolved.

Thanks! That fixed the issues with our mirroring job.

@jeffreytolar great!


Produce individual service checks

The actual version returns
<<<check_mk>>>
Version: 1.0
AgentOS: HomeAssistant
0 Supervisor connected=1 Supervisor reports Connected
0 Supported connected=1 Supported reports Supported
0 Healthy connected=1 Healthy reports Healthy

which produces an ok status for the "agent".
With
21a22
>   print('<<<local>>>')
50,51c51
<   print(code + ' ' + service + perf + service + ' reports ' + nicestatus)
<
---
>   print(code + ' ' + service + ' -' + perf + service + ' reports ' + nicestatus)

one gets three additional services with its individual status:
<<<check_mk>>>
Version: 1.0
AgentOS: HomeAssistant
<<<local>>>
0 Supervisor - connected=1 Supervisor reports Connected
0 Supported - connected=1 Supported reports Supported
0 Healthy - connected=1 Healthy reports Healthy

https://pasteboard.co/cTalQ0xCEvrt.png

Confirmed this bug.  When run without the CMK agent, the local header needs to be inserted to report service statuses.


Fix runtime error within example

When setting this code up, I hit one tiny roadbump. My console reported that strip.stripLength() is no longer supported:
Error: NotImplemented: stripLength is no longer supported

I guessed that strip.length was the new prop and it seems to work.

lol whoops, against my own fork..


Add support for printing to stdout

We should add the option to dump into stdout in case the "reportPath" param is empty in the constructor.

We should add the option to dump into stdout in case the "reportPath" param is empty in the constructor.

Why we should? What would be the use case?
And in general, it'd be better to be explicit and have a parameter that enables stodout rather than relying on an implicit behaviour.

that is because on an early version of the k8sreporter (before it had its own repo) it could
output into stdout, as the sriov uses it until today.
see: https://github.com/k8snetworkplumbingwg/sriov-network-operator/blob/1c6e1b3b1f6d70882d6245e5ccff4e9b70bf3948/test/conformance/test_suite_test.go#LL53C6-L53C6

And I'm interested in upgrading sriov's reporter to this

I bet no one is using that mode, however it's fine, as long as we have an explicit parameter as I wrote above

I discussed this with Sebastian and he agreed that we can omit this ability.


chore: renove secrets remove

part 2 https://docs.renovatebot.com/self-hosted-configuration/#npmjs-registry-token-example

:tada: This PR is included in version 1.30.1 :tada:
The release is available on:

v1.30.1
GitHub release

Your semantic-release bot :package::rocket:


minor updates and runbook structure

update to latest template-documentation-site version
add build-and-test workflow
update workflow actions
add CNAME record to prevent cert failures
add runbooks, joining-our-team, and ways-of-working folders

Basic structure looks good to me. Do we want to split out the runbook further or just have as a single page?

Runbooks can be added as separate pages, I like AP's runbook style


Misc fixes tests

This is mainly two things:

Solves https://github.com/ejnnr/cupbearer/issues/19
And marks test_train_mahalanobis_advex as flaky

2 is the questionable one. It adds a new dependency to run test-suite and that dependency has questionable maintenance. Additionally, it would be better to just fix test so that it isn't flaky, but I got a bit annoyed and wanted a quick-fix.
Shouldn't need much review. Either cherry-pick only 1 or merge as is.

There are some remaining warnings in tests, mostly from import handling deprecations internally in lightning when I'm using python3.11 but also when deprecation warning for torch.meshgrid, which made me uncertain if we're using it correctly. See https://github.com/pytorch/pytorch/issues/50276
For square images it shouldn't matter, but I'll have to look at it again to be sure that it works in general.

So actually looked at why advex test was flaky and at a first glance it shouldn't be (not strict comparisson)
rob_acc > cfg.success_threshold

but rob_acc in torchattacks is actually in percent https://github.com/Harry24k/adversarial-attacks-pytorch/blob/master/torchattacks/attack.py#L298 so my fix is to scale these to same unit. Possibly we'd like a test that sees that attack can succeed, but with these (basically) untrained models it seems that there are sometimes attacks can't succeed so anything less than 100 % success_threshold could fail then.

Finally no warnings 
==================================================================================== test session starts =====================================================================================
platform linux -- Python 3.11.5, pytest-7.4.3, pluggy-1.3.0
rootdir: /home/vikren/Documents/Private/SERI-MATS/Research/cupbearer
configfile: pytest.ini
collected 35 items

tests/test_abstractions.py ............                                                                                [ 34%]
tests/test_data.py .............                                                                                [ 71%]
tests/test_pipeline.py .......                                                                                [ 91%]
tests/test_utils.py ...                                                                                [100%]

==================================================================================== 35 passed in 10.59s =====================================================================================


Community section in README

Provide links to the typescript client #10 by @jakiestfu and the ruby guide #39 by @kmcphillips

I'm sorry, I don't understand what you did here.
You added a link to documentation here, but that link is a 404 because you closed #39 rather than merging it. Where do you want the documents to be?

@chigozienri @dmarx The docs now have a 404 here because you closed #39 rather than merge it. I don't understand what you're trying to accomplish. Should I move it to another spot?

@chigozienri @dmarx The docs now have a 404 here because you closed #39 rather than merge it. I don't understand what you're trying to accomplish. Should I move it to another spot?

I intended only to include the link to the file in your fork in the community-contributed section. New PR here. Thanks!


Deploy vue app to GitHub pages

As a short term hosting solution while we work on converting the UI to our new API, let's just host on GitHub pages.
https://github.com/marketplace/actions/vue-to-github-pages

The linked action doesn't provide much benefit as far as I can tell and also seems to assume Vue 3 is necessarily being built with Vite (not true, and is not true of our frontend, yet).
The deploy workflow here should work just fine:
https://github.com/monarch-initiative/monarch-ui-new/blob/main/.github/workflows/deploy.yaml
but we'll have to work out where else to host the documentation.
Or, you could technically host both of them on GitHub Pages. You'd put the docs in a sub folder like /docs on the gh-pages branch, and make sure the deploy-frontend workflow never overwrites it or touches it, and make the deploy-documentation workflow deploy to that folder. Pro: same url/domain and one less new place for users to remember. Con: 404s will need to go to the main UI/app and not to the docs site.

A quick mostly dev deployment is up at https://monarch-api.netlify.app for now
But we probably want to meet up sometime and make a more concrete decision about deployment for the UI and docs

Implemented in #154
Currently at https://monarch-app.monarchinitiative.org/ (hosted on GitHub Pages)
/docs should also include the mkdocs docs.


Documentation doesn't match latest NuGet package

I just noticed that a new version has been published to NuGet only the documentation doesn't explain how to use the new API. Specifically it wasn't clear how to use the new Template caching

Do you mean this?
Any change to be more concrete or directly sending a pull request to https://github.com/Antaris/RazorEngine/blob/develop/doc/Caching.md?

Nope, I mean this: http://antaris.github.io/RazorEngine/
The quick start code doesn't match the method signatures in the latest NuGet version. E.g. I can't provide a string for the templateKey in RunCompile, it's not an ITemplateKey type

Ah because those are extension methods and you need to open the RazorEngine.Templating namespace, this is tricky now. Thank you for the hint I will add that to the docs.

The docs are now updated. Thanks again for reporting.

Ahh I see, thanks for the info


Test and publish the ios driver

still isnt a good abstraction of this gradle nonsense but i dont really want to think about it a ton.....

put an intentionally failing test in there to make sure it fails the build....https://travis-ci.org/square/sqldelight/jobs/457243726


fix Issue 14975 - DMD refuses to inline even trivial struct constructors

https://issues.dlang.org/show_bug.cgi?id=14975

LGTM. Seems like a minor leftover had emmense effect on the inliner.

Similar thing here? https://github.com/D-Programming-Language/dmd/pull/5033/files#diff-9450861ae2d65b41bed0152bb8f8e6e4R1765

Seems like a minor leftover had emmense effect on the inliner.

Fortunately, now we have a means of testing whether something got inlined or not - pragma(inline, true) - which can be used to prevent such regressions in the future. I had not anticipated that when I implemented it.

Auto-merge toggled on

This pull request introduced a regression:
https://issues.dlang.org/show_bug.cgi?id=15207


ModuleNotFoundError: No module named 'elftools'

Traceback (most recent call last):
File "/Users/mojun/Documents/QianXun/project/9club/FlutterProject/flutter_old_base/Blutter/blutter/blutter.py", line 168, in
main(args.indir, args.outdir, args.rebuild, args.vs_sln, args.no_analysis)
File "/Users/mojun/Documents/QianXun/project/9club/FlutterProject/flutter_old_base/Blutter/blutter/blutter.py", line 99, in main
from extract_dart_info import extract_dart_info
File "/Users/mojun/Documents/QianXun/project/9club/FlutterProject/flutter_old_base/Blutter/blutter/extract_dart_info.py", line 4, in
import requests
ModuleNotFoundError: No module named 'requests'

Traceback (most recent call last):
File "/Users/mojun/Documents/QianXun/project/9club/FlutterProject/flutter_old_base/Blutter/blutter/blutter.py", line 168, in
main(args.indir, args.outdir, args.rebuild, args.vs_sln, args.no_analysis)
File "/Users/mojun/Documents/QianXun/project/9club/FlutterProject/flutter_old_base/Blutter/blutter/blutter.py", line 99, in main
from extract_dart_info import extract_dart_info
File "/Users/mojun/Documents/QianXun/project/9club/FlutterProject/flutter_old_base/Blutter/blutter/extract_dart_info.py", line 10, in
from elftools.elf.elffile import ELFFile
ModuleNotFoundError: No module named 'elftools'


Support for non-standard list indents

We needed list content indent = 3

Thanks. Will merge and make a release shortly.


Update migrate-stv1-to-stv2.md

There was a confusing note that I removed ("Note to contact support"). Seems like it was a placeholder since it is mentioned elsewhere in the doc.

@dlepow

Can you review this PR?
IMPORTANT: When this content is ready to merge, you must add #sign-off in a comment or the approval may get overlooked.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Fix the naming of exported measures and views from ochttp

For example, ClientRequest should be called ClientRequestCount, ClientRequestCount should be called ClientRequestCountView.
Name the measures and views consistently with the gRPC measures/views. https://godoc.org/go.opencensus.io/plugin/grpc/grpcstats.
There is no need to have multiple naming conventions.

ClientRequestCount as a view doesn't seem right. "Count" is an aggregation function so part of the view, not the measure. I will think about it some more.
I also think that the views should maybe be all collected into a single var DefaultViews []*View to make it clearer that these are just defaults, not the only ones that you can define.

Maybe it should be called ClientRequests.
Regardless of what we are doing here, we should apply it to the grpcstats packages. It is confusing to have inconsistent naming of measures/views in the same project.

Agh, wrong issue number in Fixes comment


[FEATURE REQUEST] Adding USRBG

Have you ever thought about adding USRBG? I think it would be a nice addition.

will do with next update, only for bd though cause of powercords guidelines

out now!


Changed cryptic name of the downloaded zip file to its original name

Fixes #1066.
Removes the cryptic name of the download zip file.

Test Server:
http://secure-meadow-20680.herokuapp.com/

@aayusharora @mariobehling Please review. Thanks

Codecov Report

Merging #1113 into development will decrease coverage by -0.05%.
The diff coverage is 50%.

@@               Coverage Diff               @@
##           development    #1113      +/-   ##
===============================================
- Coverage        62.56%   62.51%   -0.05%
===============================================
  Files                8        8
  Lines             1349     1350       +1
  Branches           210      210
===============================================
  Hits               844      844
- Misses             505      506       +1

Impacted Files
Coverage Δ

src/backend/mailer.js
68.23% <50%> (-0.82%)
:x:

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 bd2c8df...607b9b1. Read the comment docs.