amass: 3.15.0 -> 3.15.1

Motivation for this change
Update to latest upstream release 3.15.1
Change log: https://github.com/OWASP/Amass/releases/tag/v3.15.1
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 147772 run on x86_64-linux 1

1 package built:

amass


Added Randomized Leaky ReLU operator to Keras

Added advance activation function Randomized Leaky ReLU to keras layer

@tanzhenyu @hgadig , can you pls have a look, i have updated everything as per your review comments

Thanks. But can you please rebase as I can see there are branch conflicts. Rebase would solve this.

@hgadig & @tanzhenyu , i have rebased, pylint and tested the code, kindly approve and merge

@hgadig & @tanzhenyu , i have rebased, pylint and tested the code, kindly approve and merge

@tanzhenyu  Could you please take a look and approve this.

@tanzhenyu & @hgadig , i have fixed all the issues pointed out, again did the pylint, (even spell check this time) and tested the code

Also I think it makes more sense to place it in tensorflow addons, instead of tf.keras.
Please see: https://github.com/tensorflow/addons
(In general we only maintain that in core once the api and implementation is near finalized)

@tanzhenyu , this is advance activation function which is implmented by many frameworks including pytorch, you can refer to it and see that this activation function is put along with other activation functions, i feel this folder might be the correct place for the same, let me know what you feel.

Nagging Reviewer @tanzhenyu: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 14 days with no activity and the awaiting review label has been applied.

Nagging Reviewer @tanzhenyu: You have been added as a reviewer to this pull request. Please add your review or reassign. It has been 29 days with no activity and the awaiting review label has been applied.

Same comment as before, we could put them in add-on.

@tanzhenyu, thanks for the review, as suggested i am closing the PR.
Regards
Amit


Add a summary of the specific gameplay differences

At present, the project offers a general overview of the it's purpose and differences from the original Epic 40,000 texts, at About this publication — but no single, specific list of actual changes to gameplay.
Whilst we do include footnotes to identify and explain the differences where they occur, it'd still be helpful to summarise these in one place, to list to expand on the general explanation — even though actual gameplay differences are few and modest.
We discussed this a little in a thread in the Facebook group, which prompted me to log this ticket. As a starting point, refer to the list that Ian created off the top of his head in that thread:

Anti Tank changed to Macro Weapon. This is just a cosmetic change with no in-game difference.
Cavalry ability split into the movement and unit type part, and the +1 Armour part. This has little effect on army lists as most of the existing Cavalry units now have both abilities. I think it’s just Fleshhounds where I removed the +1 Armour part.
Infiltrators(1) that are 30-60 cm from their HQ are now just standard parts of the detachment in assaults and for shooting etc. This is largely because we couldn’t work out how the original rules were supposed to work, even with some assistance from Andy Chambers!
I’m not sure we got all parts of the Flyer rules the same as the original, again due to the original text not being quite complete.
The Speed attribute split into two values for most units, as it’s easier to read for Cavalry etc.
Several new abilities added, mostly for new factions that didn’t exist at the time.

(1) Note that there may be more to come with the Infiltrators ability rules, as per #50.
Many of those aren't really gameplay differences, but might still be helpful to list I guess. Others of the top of my head include:

Tweaks we made to the transport rules to even out issues that can occur with the various different base sizes and shapes that players use with their miniatures.

This sounds like a great idea.

Of course, given that we've been at pains to mark up meaningful differences with footnotes, a quick and dirty way for people to find these to review for themselves is:

Use the project's search tool with a query like: +difference from +Epic +40,000
Use the Google search tool with a query like: site:epicremastered.com "Difference from Epic 40,000:"


Observable calculator mode

The issue
It is currently hard for CCL to support arbitrary non-standard cosmologies. E.g. imagine we're told by someone in TJP that they want to explore an early Dark Energy model with neutrinos, warm dark matter and Vainshtein screening, and accounting for baryons using HMCODE. Including each of those consistently in CCL would take a lot more work than we can support. These things, however, are implemented in different versions of CAMB/CLASS etc.
The proposed solution
We enable a "calculator mode" for CCL so it can take in basic observables (distances, power spectra) from these and use them consistently to carry out calculations of more complex quantities (shear/galaxy power spectra, correlation functions, halo model stuff). This would also make CCL easier to integrate into likelihood frameworks like cobaya or cosmosis. When we've discussed this in the past, it was well received, so I'm hoping this is not too controversial.
The specifics
Here's a concrete proposal of what the new API would look like. There's a chance that none of the previous API would have to be deprecated, but we'll see.
1. Declaring a Cosmology
Although ideally we would like the CCL Cosmology object to not care about cosmological parameters when in "calculator mode", in practice many of the higher-level calculations we do (e.g. halo model) do need to know e.g. what Omega_M is. So, instead of subclassing the Cosmology class into a calculator-mode object, I propose that we just add 3 more arguments to its __init__ method, which will trigger the calculator mode:

background: a dictionary with three items: "a", an array of scale factor values, "h_over_h0" an array with H(a)/H(a=1), and "chi", an array containing the comoving radial distance to scale factor a. If None, CCL will compute these on its own.
pk_lin: a dictionary in the form {'a': a_arr, 'k':k_arr, 'q1_x_q2': pkq1q2}, where a_arr is an array of scale factors, k_arr is an array of comoving wave numbers, and pkq1q2 is a 2D array containing the linear power spectrum between quantities q1 and q2 sampled at the values of a_arr and k_arr. The intention is that q1 and q2 could be any of e.g. these quantities. There can be an arbitrary number of q1_x_q2 combinations, with any names you want, but at least one of them should be delta_matter_x_delta_matter, designating the linear matter power spectrum. CCL will create Pk2D objects out of all of these and will store them at the python level. The C-level linear power spectrum structure attached to a C-level cosmology structure will disappear, and all interaction with the C-level functions will happen via the f2d C structures attached to these Pk2D objects. If None, CCL will just compute delta_matter_x_delta_matter on its own as it does right now.
pk_nl: same as pk_lin for the non-linear power spectrum with the following caveat: if any of the q1_x_q2 combinations listed in pk_lin is not listed in pk_nl, CCL will compute the corresponding non-linear power spectrum via its halofit implementation. This will happen for all combinations if pk_nl==None.

The default value for all these arguments will be None (i.e. the current standard behavior in CCL).
2. Impact on the rest of the API
All CCL functions that currently depend on a P(k) will take an optional p_of_k_a argument (the same way that angular_cl currently does), specifying the power spectrum that should be used for that calculation. This argument can then take 3 possible values:

None, in which case the delta_matter_x_delta_matter power spectrum is used. This will be the default value.
A string of the form q1_x_q2, specifying which of the stored power spectra should be used. If not present, an exception will be thrown.
A Pk2D object containing the power spectrum that should be used.

A quick scan of the current API tells me these functions would be affected: angular_cl, correlation_3d, correlation_multipole, correlation_3dRsd, correlation_3dRsd_avgmu, correlation_pi_sigma, sigmaR, sigmaV, sigma8, kNL, halomod_power_spectrum, halomod_Pk2D.
linear_matter_power and nonlin_matter_power will continue to return the matter power spectrum (delta_matter_x_delta_matter).
sigmaM will always use the linear matter power spectrum, since this is what is used for halo model quantities.
Thoughts? @c-d-leonard @slosar @beckermr @elisachisari @mishakb and anyone else.

A few questions:

How do we handle, if at all, non-flat cosmologies?

hoh0 is hard to look at. Maybe ha or hubble_function or w/e?

Good question. My thought was that we know when it's not flat based on the input parameters, and we use the corresponding sinn(chi) where necessary (which CCL already does). We could instead add r (i.e. the angular comoving distance) as an alternative additional item of the background dictionary (and, if not provided, then CCL's sinn(chi) is used).
about hoh0, yep, definitely.

Hello,
I have an implementation choice question: why use ‘dict’ as the type of each of the new argumentst, rather than making each be class (if any additional behavior other than attribute lookup might be added in the future) or a namedtuple (if it is clear that no behavior wil ever be needed)?
I think both the class and the namedtuple make more clear that each argument is required to have the specific attributes named, and not others. This helps readers of the code as well as tools such as IDEs, which can better provide name completion.
Best regards
Marc
From: David Alonso<EMAIL_ADDRESS>Reply-To: LSSTDESC/CCL<EMAIL_ADDRESS>Date: Monday, December 14, 2020 at 8:31 AM
To: LSSTDESC/CCL<EMAIL_ADDRESS>Cc: Subscribed<EMAIL_ADDRESS>Subject: [LSSTDESC/CCL] Observable calculator mode (#840)
The issue
It is currently hard for CCL to support arbitrary non-standard cosmologies. E.g. imagine we're told by someone in TJP that they want to explore an early Dark Energy model with neutrinos, warm dark matter and Vainshtein screening, and accounting for baryons using HMCODE. Including each of those consistently in CCL would take a lot more work than we can support. These things, however, are implemented in different versions of CAMB/CLASS etc.
The proposed solution
We enable a "calculator mode" for CCL so it can take in basic observables (distances, power spectra) from these and use them consistently to carry out calculations of more complex quantities (shear/galaxy power spectra, correlation functions, halo model stuff). This would also make CCL easier to integrate into likelihood frameworks like cobaya or cosmosis. When we've discussed this in the past, it was well received, so I'm hoping this is not too controversial.
The specifics
Here's a concrete proposal of what the new API would look like. There's a chance that none of the previous API would have to be deprecated, but we'll see.

Declaring a Cosmology

Although ideally we would like the CCL Cosmology object to not care about cosmological parameters when in "calculator mode", in practice many of the higher-level calculations we do (e.g. halo model) do need to know e.g. what Omega_M is. So, instead of subclassing the Cosmology class into a calculator-mode object, I propose that we just add 3 more arguments to its init method, which will trigger the calculator mode:

background: a dictionary with three items: "a", an array of scale factor values, "hoh0" an array with H(a)/H(a=1), and "chi", an array containing the comoving radial distance to scale factor a. If None, CCL will compute these on its own.
pk_lin: a dictionary in the form {'a': a_arr, 'k':k_arr, 'q1_x_q2': pkq1q2}, where a_arr is an array of scale factors, k_arr is an array of comoving wave numbers, and pkq1q2 is a 2D array containing the linear power spectrum between quantities q1 and q2 sampled at the values of a_arr and k_arr. The intention is that q1 and q2 could be any of e.g. these quantitieshttps://urldefense.proofpoint.com/v2/url?u=https-3A__camb.readthedocs.io_en_latest_transfer-5Fvariables.html-23transfer-2Dvariables&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=ILJ1EKvelfPIn0Cq0WOVCVfRjhhmjTQD7NxhY2T73w0&e=. There can be an arbitrary number of q1_x_q2 combinations, with any names you want, but at least one of them should be delta_matter_x_delta_matter, designating the linear matter power spectrum. CCL will create Pk2D objects out of all of these and will store them at the python level. The C-level linear power spectrum structure attached to a C-level cosmology structure will disappear, and all interaction with the C-level functions will happen via the f2d C structures attached to these Pk2D objects. If None, CCL will just compute delta_matter_x_delta_matter on its own as it does right now.
pk_nl: same as pk_lin for the non-linear power spectrum with the following caveat: if any of the q1_x_q2 combinations listed in pk_lin is not listed in pk_nl, CCL will compute the corresponding non-linear power spectrum via its halofit implementation. This will happen for all combinations if pk_nl==None.

The default value for all these arguments will be None (i.e. the current standard behavior in CCL).

Impact on the rest of the API

All CCL functions that currently depend on a P(k) will take an optional p_of_k_a argument (the same way that angular_cl currently does), specifying the power spectrum that should be used for that calculation. This argument can then take 3 possible values:

None, in which case the delta_matter_x_delta_matter power spectrum is used. This will be the default value.
A string of the form q1_x_q2, specifying which of the stored power spectra should be used. If not present, an exception will be thrown.
A Pk2D object containing the power spectrum that should be used.

A quick scan of the current API tells me these functions would be affected: angular_clhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_cls.py-23L15&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=CMGAZhYQUd_S5o9ImgHTiQSTzV4r7avEigzS1i-VNB8&e=, correlation_3dhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_correlations.py-23L113&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=r_KYGh2ios4F9rPOX-0KifG4OggaZazZSRU4hMTDu-A&e=, correlation_multipolehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_correlations.py-23L145&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=STRz3ZWwqPbSSi5F3EzNkExWXWl6cZroZ00FLYh6Qx4&e=, correlation_3dRsdhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_correlations.py-23L180&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=p5jUASpqKmebs4KBjzwpJCYUybVa5CdS5Otn2Q-W69Y&e=, correlation_3dRsd_avgmuhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_correlations.py-23L220&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=_zVHFYNxNxPqEYUdvZf5ZYiLn51Bwn0rvYyRV6gLcYg&e=, correlation_pi_sigmahttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_correlations.py-23L255&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=gAQmInAhQFsNlZKg2TkUSF2vuyYVbZVIY39IUmi-_B0&e=, sigmaRhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_power.py-23L64&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=h3GTM7ry8jaLLIQ9bqZeDrey0bcT1Ev3b80GLqSmK3o&e=, sigmaVhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_power.py-23L80&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=3PEU_RVa2VqghvURm5XdvQoFKQyp83A4OpkAKKjsT-g&e=, sigma8https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_power.py-23L97&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=eCdbue8TtxzpRq1hdGt4ZMp9C_TdatGeypTouVsG10c&e=, kNLhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_power.py-23L113&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=5l4kIoDKjgNvR6YQo8sGQ4nNOksIycVOZI199NyjpHY&e=, halomod_power_spectrumhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_halos_halo-5Fmodel.py-23L406&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=i57PP9rToxoaGu4V25IHaX6Vbnw91T4b_qYlCCIwQeo&e=, halomod_Pk2Dhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_halos_halo-5Fmodel.py-23L540&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=vsFAMtvkCx2wz09YnKXJMYybV77QTpwomPirlaOz0Es&e=.
linear_matter_powerhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_power.py-23L7&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=MHB0IGCSGuxSR-CG3TLdH7hugw9KNic9gWR0327NcZ8&e= and nonlin_matter_powerhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_power.py-23L23&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=FlJG1hGutL9AZ0N6OELcQhMil_im7y-ucO5aphnSuAc&e= will continue to return the matter power spectrum (delta_matter_x_delta_matter).
sigmaMhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_blob_593ed60ce7d9763590856fd253e6683ca18269f5_pyccl_power.py-23L39&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=5n4sFltrKcr_7eU4Fgr9TNuFyjyfuX_n_3bxTr279q8&e= will always use the linear matter power spectrum, since this is what is used for halo model quantities.
Thoughts? @c-d-leonardhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_c-2Dd-2Dleonard&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=keZDag139L0YeEUfbQpDOOmQXUM_f1LeFXQYcqZkWzM&e= @slosarhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_slosar&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=s25E_V4ai_7EoumFr_-W3bvcxA3g6Rt2e7m6ibtMHmo&e= @beckermrhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_beckermr&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=NTClznriDFBCEZjNGu_P3-1aZS9wcSrP-sdO1WSeMKY&e= @elisachisarihttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_elisachisari&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=dXu08U_Q6-dmG9pR1PeXPkwsiHQUMp5R1tk9hx3dxJ0&e= @mishakbhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mishakb&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=xjX9FzD638dXQm0LTQGrB2L3DDJ_lzv6asMiGyFsEjE&e= and anyone else.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_issues_840&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=OJ-W1B8Pd2EdjQEbogLe-fSDO3stF6JOUhnilnu0Fyk&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AABMJX5X4I5R5OU64DGUVLLSUYOT3ANCNFSM4U22QUPA&d=DwMFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=GWsTyjvEMBdlDKGXbEn8zlR5sYgywQBMfnafw5qj0jI&s=QYU8OLVXdF6q44i48aX5mDvzUmw8w9lQGArQn-AqHek&e=.

Classes and named tuples introduce mental overheads for users (i.e. which class do I need to pass here? how do I make that class?)
They are also more difficult to serialize.
Nearly everyone using python will know how to make a dictionary quickly.

I think in general this proposal is good and well thought-out abstraction and in particular allows you to have beyond matter fields (y, etc.). I think it is ok to leave a few named parameters to have special meanings. I.e. Om is used for lensing kernel and Ok to apply sin/sinh as appropriate.  I think with this we can make a fairly general "calculator".
A few things:

you could imagine a way of passing a few optional fields Om(z) and also something that would allow lensing in more complex sitautions (mu!=psi whatever). These should be strictly optional.
how to deal with RSD type corrections?
Could we find a way that the fields are not pre-interpolated but instead you can pass a function to eg.. calculate hoh0? for example hoh0 = lambda a : np.sqrt(Om/a3+Ox/a2+Oy/a+Ol) ? Is this of any use at all? Could be useful for e.g,. SN testing something, etc.

Hi again,
I will concentrate on what I see as the advantages using a class, rather than a dictionary with specified keys and types of values, because I think that is actually the better solution than the namedtuple. I am ignoring issues of syntax here, because I think they are relatively minor.
I think for the reader (and code is read more often than written), the use of a well-named class and documented class introduces less mental overhead than does use of a dictionary. The class stresses what the nature of the thing is: for example, a linear power spectrum, or a non-linear power spectrum, etc. Such a type gets described in one place. In an interactive session, the user can query the object and find this documentation; development tools will allow access to this information. Automated tools can perform name-completion on data members. The type has meaning.
Use of a dictionary object does not provide these advantages.
Best regards,
Marc
From: "Matthew R. Becker"<EMAIL_ADDRESS>Reply-To: LSSTDESC/CCL<EMAIL_ADDRESS>Date: Monday, December 14, 2020 at 9:25 AM
To: LSSTDESC/CCL<EMAIL_ADDRESS>Cc: Marc F Paterno<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [LSSTDESC/CCL] Observable calculator mode (#840)
Classes and named tuples introduce mental overheads for users (i.e. which class do I need to pass here? how do I make that class?)
They are also more difficult to serialize.
Nearly everyone using python will know how to make a dictionary quickly.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_LSSTDESC_CCL_issues_840-23issuecomment-2D744514216&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=TR3SPI-yitwRFlaAgTRkRAZJ0HWIIM2FQhMQSHHGU1Y&s=fw_T0_WbmZdrSGeYPuSYR_utytQ1_jlB22Pop8ByhAo&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AABMJXZB73EEUMMBYIWIMZTSUYU5NANCNFSM4U22QUPA&d=DwMCaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=d3p0PLQb2ItFxNVHOOIv2g&m=TR3SPI-yitwRFlaAgTRkRAZJ0HWIIM2FQhMQSHHGU1Y&s=y9PfwF_fkH_7mbRIgfb-ny8AsYdON5n7zcjgSsAHDDY&e=.

Hello David,
The “calculator_mode” is precisely the conversion we have - here at UofA - implemented on Cosmolike to be integrated w/ Cobaya Sampler to evaluate more general cosmologies (a project we called Cocoa - https://github.com/CosmoLike/cocoa). Cosmolike receives power spectrum (both linear and non-linear) and background quantities (like distances) and then perform further complex calculations like shear/clustering.
One technical aspect we faced is that functions that were super fast in the past - like H(z) that was previously an analytical function - now are splines (much slower), and depending on how deep these calls are in the code - it can make a noticeable difference in execution time.
Another important technical aspect was threading - extensions to LCDM are slower to calculate - and we don’t want to have each walker on our samples to not walk past enough their initial conditions - so OpenMP threading was required - and that required some significant changes.
It took us many months to apply all these changes - it is a significant infrastructure project (awesome - but hard!) to do that on CCL based on our experience w/ Cosmolike.
Best Regards
Vivian Miranda
On Dec 14, 2020, at 7:31 AM, David Alonso <notifications<EMAIL_ADDRESS>wrote:
External Email
The issue
It is currently hard for CCL to support arbitrary non-standard cosmologies. E.g. imagine we're told by someone in TJP that they want to explore an early Dark Energy model with neutrinos, warm dark matter and Vainshtein screening, and accounting for baryons using HMCODE. Including each of those consistently in CCL would take a lot more work than we can support. These things, however, are implemented in different versions of CAMB/CLASS etc.
The proposed solution
We enable a "calculator mode" for CCL so it can take in basic observables (distances, power spectra) from these and use them consistently to carry out calculations of more complex quantities (shear/galaxy power spectra, correlation functions, halo model stuff). This would also make CCL easier to integrate into likelihood frameworks like cobaya or cosmosis. When we've discussed this in the past, it was well received, so I'm hoping this is not too controversial.
The specifics
Here's a concrete proposal of what the new API would look like. There's a chance that none of the previous API would have to be deprecated, but we'll see.

Declaring a Cosmology

Although ideally we would like the CCL Cosmology object to not care about cosmological parameters when in "calculator mode", in practice many of the higher-level calculations we do (e.g. halo model) do need to know e.g. what Omega_M is. So, instead of subclassing the Cosmology class into a calculator-mode object, I propose that we just add 3 more arguments to its init method, which will trigger the calculator mode:

background: a dictionary with three items: "a", an array of scale factor values, "hoh0" an array with H(a)/H(a=1), and "chi", an array containing the comoving radial distance to scale factor a. If None, CCL will compute these on its own.
pk_lin: a dictionary in the form {'a': a_arr, 'k':k_arr, 'q1_x_q2': pkq1q2}, where a_arr is an array of scale factors, k_arr is an array of comoving wave numbers, and pkq1q2 is a 2D array containing the linear power spectrum between quantities q1 and q2 sampled at the values of a_arr and k_arr. The intention is that q1 and q2 could be any of e.g. these quantitieshttps://camb.readthedocs.io/en/latest/transfer_variables.html#transfer-variables. There can be an arbitrary number of q1_x_q2 combinations, with any names you want, but at least one of them should be delta_matter_x_delta_matter, designating the linear matter power spectrum. CCL will create Pk2D objects out of all of these and will store them at the python level. The C-level linear power spectrum structure attached to a C-level cosmology structure will disappear, and all interaction with the C-level functions will happen via the f2d C structures attached to these Pk2D objects. If None, CCL will just compute delta_matter_x_delta_matter on its own as it does right now.
pk_nl: same as pk_lin for the non-linear power spectrum with the following caveat: if any of the q1_x_q2 combinations listed in pk_lin is not listed in pk_nl, CCL will compute the corresponding non-linear power spectrum via its halofit implementation. This will happen for all combinations if pk_nl==None.

The default value for all these arguments will be None (i.e. the current standard behavior in CCL).

Impact on the rest of the API

All CCL functions that currently depend on a P(k) will take an optional p_of_k_a argument (the same way that angular_cl currently does), specifying the power spectrum that should be used for that calculation. This argument can then take 3 possible values:

None, in which case the delta_matter_x_delta_matter power spectrum is used. This will be the default value.
A string of the form q1_x_q2, specifying which of the stored power spectra should be used. If not present, an exception will be thrown.
A Pk2D object containing the power spectrum that should be used.

A quick scan of the current API tells me these functions would be affected: angular_clhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/cls.py#L15, correlation_3dhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/correlations.py#L113, correlation_multipolehttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/correlations.py#L145, correlation_3dRsdhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/correlations.py#L180, correlation_3dRsd_avgmuhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/correlations.py#L220, correlation_pi_sigmahttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/correlations.py#L255, sigmaRhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/power.py#L64, sigmaVhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/power.py#L80, sigma8https://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/power.py#L97, kNLhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/power.py#L113, halomod_power_spectrumhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/halos/halo_model.py#L406, halomod_Pk2Dhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/halos/halo_model.py#L540.
linear_matter_powerhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/power.py#L7 and nonlin_matter_powerhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/power.py#L23 will continue to return the matter power spectrum (delta_matter_x_delta_matter).
sigmaMhttps://github.com/LSSTDESC/CCL/blob/593ed60ce7d9763590856fd253e6683ca18269f5/pyccl/power.py#L39 will always use the linear matter power spectrum, since this is what is used for halo model quantities.
Thoughts? @c-d-leonardhttps://github.com/c-d-leonard @slosarhttps://github.com/slosar @beckermrhttps://github.com/beckermr @elisachisarihttps://github.com/elisachisari @mishakbhttps://github.com/mishakb and anyone else.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/LSSTDESC/CCL/issues/840, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAYP32GRYPZBO5JU5SDYWITSUYOT5ANCNFSM4U22QUPA.

Hi Again,
Below, I show an example of the changes we had to perform. The weights in the weak lensing evaluations are deep inside integrals. With excessive splines evaluations, code was slowed down by O(1). To fix that, we had to expand the input of their functions call to avoid repetition of interpolation evaluation
double W_gal(double a, double nz, double chi, double hoverh0)
Here is a snippet of one integrand in clustering (Cosmolike)
double int_for_C_cl_tomo(double a, void *params) {
  double *ar = (double *)params;
  struct chis chidchi = chi_all(a);
  const double hoverh0 = hoverh0v2(a, chidchi.dchida);
  const double ell = ar[2] + 0.5;
  const double fK = f_K(chidchi.chi);
  const double k = ell / fK;

  const double res = W_gal(a, ar[0], chidchi.chi, hoverh0) *
    W_gal(a, ar[1], chidchi.chi, hoverh0) * chidchi.dchida/(fK * fK);
  return res * Pdelta(k, a);
}

There is no need to understand the detail of the entire function - but just see the effort to avoid repeated interpolation evaluations of background quantities at the cost of readability.
In summary - the calculation mode may ask for big API changes in the code to match the original CCL speed requirements (based on our experience in Cosmolike) - such changes can make CLL harder to maintain and trickier to expand. That is choice (optimized code vs readable code). When doing an extension to LCDM - the speed requirement is so severe that the code needs to be more optimal.

@slosar : is your question about RSD corrections specific to calculator mode (e.g. how to specify and pass in arbitrary P(k,mu) or multipoles), or more generally about CCL doing RSD calculations. I ask b/c @sukhdeep2 and I have been discussing adding functionality to the correlation functions that would help with RSD.

@damonge : I assume we should still continue with the much lighter weight general correlation function implementation (#815 )

I'm really sorry for missing the discussion today, and for the delay in responding.
Thanks everyone for their comments. Here are some thoughts:
@marcpaterno thanks a lot. While I see your point, I'm gonna side with @beckermr on this one. First, I actually agree that there's a mental overhead to classes for users. On the other, having to write code for those classes will mean having to maintain that code, and I'd rather not have to do that for now. Nevertheless, it should be easy to allow the class option if we think it works better afterwards.
@vivianmiranda thanks a lot, this is really useful information. On the spline-vs-analytical tradeoff, I think we've gone far enough down the spline route in CCL that the current performance will probably not change much after including these modifications. That doesn't mean that CCL is as fast as it could be, of course, and knowing that this kind of stuff played a role is useful.
I didn't understand this point, could you elaborate?

Another important technical aspect was threading - extensions to LCDM are slower to calculate - and we don’t want to have each walker on our samples to not walk past enough their initial conditions - so OpenMP threading was required - and that required some significant changes.

@slosar

Regarding Om(z): my hope is that, once this is implemented, we won't really need Om(z) or Sigma/mu at all. Users will just use the right power spectrum (Weyl potential) when computing observables involving lensing, which will include all of these prefactors.
Regarding RSDs. If we're talking about the C_ell-level RSDs, I guess the same logic would be at play. Users should use the right power spectrum (velocity divergence) when constructing the C_ells. We should however ensure that there's an easy way of doing that for the standard tracers we support, and I have some ideas on that end (associating tracers with 3D quantities), but I'd like to implement the simpler API first before complicating things.
Regarding passing functions instead of arrays: we could support these quantities being functions instead of arrays, but the only way to communicate between python and C is through arrays and spline objects, so those functions would need to be splined and passed to C anyway. If having functions is still useful, we can support it, but there's no way around splines in the calculator mode, I think.

@jablazek

I think #815 would be solved once this is in place, since all of those functions will be able to take in arbitrary power spectra (unless I'm missing something).
About RSDs at the P(k,mu) level: not sure what you guys are planning. Probably best to have a chat before trying to guess ;-)

@damonge, of course, I am happy to elaborate on my point. For reference, I will quote the paragraph again.

Another important technical aspect was threading - extensions to LCDM are slower to calculate - and we don’t want to have each walker on our samples to not walk past enough their initial conditions - so OpenMP threading was required - and that required some significant changes.

Let's do this thought experiment:
Pipeline 1: total runtime for 3x2 is ~O(1) second w/ 4 cores (OpenMP)
Pipeline 2: total runtime for 3x2 is ~O(10^2) seconds (no OpenMP threading available).
You use 400 cores to run a single chain on pipeline 1 and 10^4 cores to run a single chain on pipeline 2.

Pipeline one: you set Emcee to have 100 fast walkers (MPI threads) - each walker has 4 OpenMP threads
Pipeline two: you set Emcee to have 10^4 walkers (MPI threads).

You then ask Emcee to give you 10M samplers.
Both pipelines one and two should take the same time to evaluate the 10M samplers in these configurations.
Given all that, my point is: I suspect the convergence tests in the chain run w/ pipeline two will provide much worse results (the standard test is basically checking if walkers walked O(>>1) their correlation length) - because walkers are just stuck on volumes in parameter space around their initial condition (because they are all super slow - no way to move past their IC location even if they want!).
Given that - if CCL is already O(20s) and if the calculator mode increase that runtime even more - that would worry me.
Best
Vivian

@damonge - one more point: the counter-argument to my previous message is:
"Vivian (talking to myself in the third person - I love to do that pretending I have multiple personalities to discuss physics while at home :p uahauh) - but w/ more MPI threads each walker will walk smarter" - qualitatively, that is true, but this is a fine line.
Best
Vivian

@vivianmiranda ok, thanks. I don't think CCL is O(20s), but regardless of that, this is a good point. We should add a timing unit test to make sure performance doesn't suffer when we add this (which we should have done already).

Ok, I think we should not sidetrack this discussion into emcee performance discussion. (you have a valid point, it is well known that MCMC algorithms don't scale beyond a certain point because the computation cost per node is to take Nburnin + Nsamples/Nnodes samples and once the first term dominates the game is over.
@damonge Yes, I missed the beauty of having arbitrary fields. This makes it very general. Also, I got temporarily sidetracked into thinking this is about enabling more models, but it is primary about enabling integration with Cosmosis and Cobaya with the caching being stuck upstream.   It is still worth thinking if we can do any further caching inside CCL Calculator mode. Say Pklin changes, but not expansion history? I don't think it make any difference, but you never know...

@damonge :
For the RSD issue, after reading your comments to @slosar, I think we are talking about slightly orthogonal issues. We are looking at expanding the correlation function capability to do fast calculations including RSD contributions. Of course the velocity Pk will need to come from somewhere, but we are agnostic about that for the time being.
Regarding #815, I think the earlier consensus was that it would be good to expose all of the correlation functions (not just the 2d C_ell -> w(theta) one) to a user specified (k,Pk), rather than being limited to the cosmology object's internally defined Pmatter). The modifications for implementing calculator mode may do this anyway, but I think this is a function that should be allowed without using a separate calculator API.

OK, great.
For RSD in correlation functions: in principle I guess you'll need P_gg, P_gv and P_vv. If you can come up with an API for ingesting those and giving you the right correlation function, I don't see any problems with the calculator mode.
Re #815, yes, I agree. This can happen independently or as part of the calculator revamping. The result should be the same.

For anyone keeping an eye, the PR that implements this is ready: #843


Additional File Functions

This PR:

[ ] Adds CreateFile() - Can be used by twisted.python.lockfile to create files which can be read but not written to.

[ ] Add test to check for proper behavior of CREATE_ALWAYS and ERROR_ALREADY_EXISTS
[ ] Add test for the new LP_SECURITY_ATTRIBUTES structure.

[ ] Adds LockFileEx() - So a file can be locked while operations can be performed.
[ ] Adds UnlockFileEx() - To reverse a held lock.

Current coverage is 92.44%

Merging #61 into master will decrease coverage by -4.08% as of af031e2

Powered by Codecov. Updated on successful CI builds.


How to use "getUrl"?

I used getUrl: true but then what should i do?? thanks

Hello, this library is just a wrapper over yt-dlp/yt-dlp
I recommend to check the documentation there 🙂


Make addTx go directly to the socket based node.

Pre-submit checklist:

Branch

[ ] Commit sequence broadly makes sense
[ ] Key commits have useful messages
[ ] Relevant tickets are mentioned in commit messages

PR

[ ] Self-reviewed the diff
[ ] Useful pull request description
[ ] Reviewer requested

If you updated any cabal files or added Haskell packages:

[ ] nix-shell shell.nix --run updateMaterialized to update the materialized Nix files
[ ] Update hie-*.yaml files if needed

If you changed any Haskell files:

[ ] nix-shell shell.nix --run fix-stylish-haskell to fix any formatting issues

If you changed any Purescript files:

[ ] nix-shell shell.nix --run fix-purty to fix any formatting issues

Pre-merge checklist:

[ ] Someone approved it
[ ] Commits have useful messages
[ ] Review clarifications made it into the code
[ ] History is moderately tidy; or going to squash-merge

Fixes #SCP-1982 and #SCP-1983.

I have tested if this change affects the ChainIndex service, and as far as I can see everything works now (there was a problem with the client failing to connect, but I made it reconnect on failure).
The second service that is using the client is the wallet, but when I tried to create a wallet on the master branch I failed to do so. The REST call just hangs, so I could not test if my changes actually work, because it does not work on master.
I would suggest we merge this one, close the related tickets, add a ticket to investigate what is happening with the Wallet, and make the remaining ticket be blocked by this new one.


ordering random, new option? it could be...

I suppose you won't have much time, but I leave you this proposal. When tournament participants register and do not reach the minimum number of brackets and have to fill out "BYE", it would be important to perform a random distribution. To avoid empty seeds in a row... at the end of creating the square brackets.
For now I continue to familiarize myself with the library. I learned javascript 15 years ago, node and ts I have to update myself. I apologize if the option exists and I have not seen it. ;Þ

do not rich the minimum number of brackets

Do you mean "do not rich the expected number of participants in the bracket"?

at the end of creating the square brackets

What are square brackets?

empty seeds in a row

Do you mean when creating multiple brackets in a row? In that case, you should be responsible to randomize the seeding, which given as a input of the library.

const eliminationOrderings: SeedOrdering[] = ['natural', 'reverse', 'half_shift', 'reverse_half_shift', 'pair_flip', 'inner_outer'];
define new SeedOrdering mode random. But as you say, we can pass the seeds in advance randomly and leave SeedOrdering = natural.
example:

órdenes de eliminación const: SeedOrdering[] = ['natural', 'reverse', 'half_shift', 'reverse_half_shift', 'pair_flip', 'inner_outer'];
define un nuevo modo SeedOrdering aleatorio. Pero como dices, podemos pasar las semillas por adelantado de forma aleatoria y dejar SeedOrdering = natural.
ejemplo:

Yes, I don't want to have anything random in the library 😁 going to close the issue


[Subtask] Connectors for Spark SQL Query Engine -> Flink Table Store

Code of Conduct

[X] I agree to follow this project's Code of Conduct

Search before asking

[X] I have searched in the issues and found no similar issues.

Describe the subtask
Flink Table Store is a unified streaming and batch store for building dynamic tables on Apache Flink. It is designed to be the best connector to Flink as the storage for streaming warehouse. The document how to use connectors for Spark SQL query engine to connect Flink Table Store should support.
Parent issue
https://github.com/apache/incubator-kyuubi/issues/3059
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

I would like to take this.

thanks, @deadwind4

Code of Conduct

[x]  I agree to follow this project's Code of Conduct

Search before asking

[x]  I have searched in the issues and found no similar issues.

Describe the subtask
Flink Table Store is a unified streaming and batch store for building dynamic tables on Apache Flink. It is designed to be the best connector to Flink as the storage for streaming warehouse. The document how to use connectors for Spark SQL query engine to connect Flink Table Store should support.
Parent issue
#3059
Are you willing to submit PR?

[x]  Yes I am willing to submit a PR!

Hi @SteNicholas   ,I‘d like to submit a PR!

@huage1994, assigned to you. Go ahead to contribute the document.


Broken user record when notification is created without an existing user

Hello!
I'm using Notifo 1.3.0, and have ran into a bug it seems.
If a notification is created for a user ID that doesn't exist yet, then subsequent attempts to create that user with the same ID will result in two broken user records. In my environment, we upsert users to Notifo with IDs that match our internal system, for ease of correlating users between the two systems. When the problem described happens, those user records are broken until we go into the Mongodb and manually remove everything related to that ID, including notifications.
Obviously, our system could handle the creation of users better to prevent this odd case from happening, but alas, it has happened and I imagine it could happen to others.
Here's a screenshot from MongoDB compass from the Users collection that shows what happens on the backend:

One user is created with the real user ID, and subsequent upserts do not replace it.
The upsert request for the user after the fact is very simple, just an email and ID:
POST http://notifo:5000/api/apps/fe05d9b4-9c98-4edd-b7cc-9de42d8f43a1/users
{
  "requests": [
    {
      "emailAddress": "ben<omitted>",
      "fullName": null,
      "id": "6a978c47-6c5b-482d-a29c-1643e8e95c45",
      "phoneNumber": null,
      "preferredLanguage": null,
      "preferredTimezone": null,
      "properties": null,
      "requiresWhitelistedTopics": null,
      "settings": null
    }
  ]
}

I'm guessing that the object with the actual user ID is created automatically so that the system can track those counters. But then subsequent upserts on that same ID do not replace it, which causes my problem.
Hope that's enough info.
Thanks!

Yes, thats definitely a bug. I will have a look.


Updates to selector bounds

This PR attempts to address the issues with the bounds from regions selected using the percentage selector (see the second item in https://github.com/cosmicds/cosmicds/issues/246#issuecomment-1640330084). The logic for the selector now takes into account how many items there should be in the percentage range, and makes sure that this is the case by either dropping the edge value further from the mean, or adding the new one closer to the mean, as necessary.
Also, some of the generic logic has been refactored out into utility functions so that it can be used in other places (e.g. calculating the relevant statistics for the student's particular class data in the Hubble story).

Looks like we're super close on this! We noticed a weird edge case with student_id=4094 where the 95% for 7 values should be highlighting everything, but instead it's highlighting 6 values, and the one it's missing is farther away from the median.

After you implement any fixes, you should make sure that student_id=4168 still behaves properly.

@patudom I think I found the issue with that 95% case and pushed a commit that I think solves it. Both of the cases we were looking at (student IDs 4094 and 4168) look good to me now; let me know what you think


security: bump uglify.js version to >= 2.4.24

The current system pulls in uglify.js at 2.4.23. There's a security advisory for this version
https://nodesecurity.io/advisories/uglifyjs_incorrectly_handles_non-boolean_comparisons
which would suggest that the thing to do is to bump to >= 2.4.24. I'll work on a PR which should be straightforward.
Found this with the help of "David", https://david-dm.org/vielmetti/node-red

The relevant underlying issue is https://github.com/mishoo/UglifyJS2/issues/751


⚠ Secret Website 1 has degraded performance

In ff73b77, Secret Website 1 ($SECRET_WEBSITE_1) experienced degraded performance:

HTTP code: 200
Response time: 9931 ms

Resolved: Secret Website 1 performance has improved in f4cf762.


Maps workflow in 1.29_v1

Hi,
Is the map selection workflow working properly in 1.29?
We had to update to 1.29 for r20.3 (preview) and it doesn't looks like the plugin generates the maps .json. I tried manually creating it and while it works for the default map, additional maps just dont work at all - returning an "INVALID" argument in d3.

Hi, there is very little difference between plugin versions 1.28 and 1.29 so I would be surprised if updating the plugin caused an issue, but it's possible there is a bug in the r20.3 prerelease. I'll investigate internally and let you know.

Are you making sure to load each map at least once and hitting 'Save Current' as you do so?
The channel/schema for the map will only be written to the JSON if you load and save it.

I've just tested again on a blank project, created two maps and some channel definitions on each. Load + save.
No .json file created by renderstream plugin.

Do you have a d3 license on the machine? If d3 is unlicenced we won’t generate json files, since the renderstream dll file is encrypted.

I tested 2 different machines:
Machine A - regular computer, no d3 license - no json being generated and the following appears in log:
LogRenderStreamEditor: Warning: RenderStreamLink unavailable, skipped GenerateAssetMetadata
Machine B - RX render node with all licenses - json generated as expected after saving any map.

That sounds like d3 isn't installed on Machine A. It's a requirement to have d3 installed - it doesn't have to be licenced, just available - all the json saving code is built into d3's install.

Yep confirmed it works fine after installing  d3 - is this mentioned anywhere or simply assumed?

Hi. Yes, this is documented in the plugins section of the user guide - https://help.disguise.one/Content/Configuring/Render-engines/RenderStream-Unreal.htm but it could do with being clearer.

This is solved and can be closed :)


Istio operator delete hangs during uninstall.

(NOTE: This is used to report product bugs:
To report a security vulnerability, please visit https://istio.io/about/security-vulnerabilities
To ask questions about how to use Istio, please visit https://discuss.istio.io)
Bug description
[ ] Docs
[ X] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Expected behavior
Should delete istio operator resources.
Steps to reproduce the bug
When i install istio by using istio-operator installation will be successful.
When i try to delete the istio-operator resources, it will get hung & never get delete.
Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)
1.9.0
How was Istio installed?
istio-operator
Environment where the bug was observed (cloud vendor, OS, etc)
Linux
Additionally, please consider running istioctl bug-report and attach the generated cluster-state tarball to this issue.
Refer cluster state archive for more details.

Can some one please take a look & suggest us on the fix.


Continuous fuzzing

Summary
I have been fuzzing Argo, and I would like to contribute my fuzzer to Argo. The fuzzer runs locally, and I have managed to get it running on oss-fuzz's infrastructure as well. I would suggest that continuous fuzzing is implemented into Argos via oss-fuzz. This will allow the current fuzzer as well as all future fuzzers continuously in search for bugs.
Continuous fuzzing has been proven to find bugs over time. A bug took several CPU years of fuzzing to find.
If Argo is accepted into the oss-fuzz project and a bug is found, maintainers on the email list receive a detailed bug report. The service is offered free of charge with an implied expectation that the bugs are fixed, so that the resources spent on fuzzing Argo are put to good use.
I will be glad to implement Argo into oss-fuzz. All I need are the email addresses to add to the mailing list of the bug reports. This list is public and can be changed at any time.
Motivation
Fuzzing is a technique that has proven effective in find bugs including vulnerabilities.
Proposal
We take two steps:

I contribute my fuzzer here on Argos repository.
An application to integrate into oss-fuzz is setup using the fuzzer on Argos own repository.

Message from the maintainers:
If you wish to see this enhancement implemented please add a 👍 reaction to this issue! We often sort issues this way to know what to prioritize.

For posterity, some fuzzers were added to the CNCF fuzzing repo: https://github.com/cncf/cncf-fuzzing/tree/07bfece/projects/argo
See also #7823 and #12031


offline

Hi @borismus ,
is it possible to get this working between two devices without the need for pairing over a web socket connection to a server. especially for those instances where both devices are offline.
BR,
josh

Sure: the audio-only transmission method sends some data, but the bandwidth
is quite low.
On Mon, Jan 19, 2015 at 5:44 AM, joshua Oguche<EMAIL_ADDRESS>wrote:

Hi @borismus https://github.com/borismus ,
is it possible to get this working between two devices without the need
for pairing over a web socket connection to a server. especially for those
instances where both devices are offline.
BR,
josh
—
Reply to this email directly or view it on GitHub
https://github.com/borismus/sonicnet.js/issues/11.


Why can't I move auth folder to root of pages

I just wanted to ask why is it that I can't move [...nextauth].js to anywhere else? I did try moving auth folder from pages/api/auth/[...nextauth].js to pages/auth/[...nextauth].js and I got the following error. It's not too important for me that it needs to be moved but just wanted to ask why is it like this?
./node_modules/typeorm/browser/driver/DriverFactory.js
Attempted import error: 'AuroraDataApiPostgresDriver' is not exported from './postgres/PostgresDriver'.

Also could you make it so NEXTAUTH_URL can be defined even from options from [...nextauth].js, I don't know why but even though I have put it in next.config.js it keeps showing:
[next-auth][warn][nextauth_url] NEXTAUTH_URL environment variable not set
https://next-auth.js.org/warning#nextauth_url

Hi there,
The directories pages and pages/api are both special in Next.js. React Pages can go in pages but API routes (i.e. Serverless functions that are not React pages) need to go in pages/api. This is an implementation detail of Next.js rather than anything about NextAuth.js.
NEXTAUTH_URL must be defined as an environment variable as per the instructions (e.g. in a .env file or in environment variables on a service like the Vercel dashboard). It needs to be accessible server and client side across routes, so defining it in [...nextauth].js directly isn't enough as pages in Next.js wouldn't be able to access it.

Oh didn't know about that /api thing, alright thank you.
This is the last one, @iaincollins
I am using django rest api as backend, and am using this package: https://github.com/SimpleJWT/django-rest-framework-simplejwt to generate jwt's from backend to be sent as authorisation header when doing data manipulation and also about the access key and such info returned by signing in using api I want it to be stored after sending it to django, the session is also maintained on rest api too.
I did check out #11 and also https://github.com/iaincollins/next-auth-example/tree/main/pages/api/examples still doesn't solve

Also I need to know how to put my own user object in session, after all if I'm passing the user info to backend rest api, it gives back a different user object, in django user object, there's something like permissions and groups, I'll need them to determine if a logged in user can edit data from frontend. By groups I mean if they are staff, moderator and such and a user can be set to be belonging to one of these and be given write, modify and delete permissions.


Merge changes for issue 781 (Reactivity)

Closes #781

@bcorrie will revisit status.

Continued discussion here: https://github.com/airr-community/airr-standards/issues/781#issuecomment-2287147890 on #781

From the call:

May need further discussion.
Tentatively, how do people feel about:

Should we change reactivity_method and reactivity_readout to free text (from an enum)?
Should we leave in Reactivity.reactivity_ref and Rearrangement.reactivity_id?

If we resolve the above, can we merge this and drop other related topics?

For the annotation use case, what about having Rearrangement.reactivity_ref as an array (or list) that points to external object IDs (as CURIEs) that denote that a specific chain has some known similarity to an externally measured record. So we aren't reusing Reactivity (with reactivity_id) to capture this, we are just treating it like an annotation for the sequence. So more like v_call which is an array/list of allele calls.
So we might have (based on this example - https://github.com/airr-community/airr-standards/issues/781#issuecomment-2077945515):
    "cell_id" : "5ed6859e99011334ac05e847",
    "junction_aa": "CASSLQSSYNSPLHF",
    "v_call": "TRBV11-2",
    "j_call": "TRBJ1-6",
    "reactivity_ref" : "IEDB_RECEPTOR:182992"

Simple... and doesn't convolute our designed use of Reactivity.
If this was a paired chain study, then you would have the alpha chain linked by cell_id:
    "cell_id" : "5ed6859e99011334ac05e847",
    "junction_aa": "CALRTDRGSTLGRLYF",
    "v_call": "TRAV9-2",
    "j_call": "TRAJ18",
    "reactivity_ref" : "IEDB_RECEPTOR:182992"

If you only care about annotated Rearranegement.reactivity_ref that were paired chains (e.g. @bussec), you can determine which rearrangements in the data have such paired chains using this model with a bit of work.
The down side is that you don't know anything about what the receptor in this case is reactive to, so in the ADC you can't ask the ADC to give me all of the chains that have documented reactivity to Insulin. You could find it out by querying IEDB, but you can't get it directly.
The other downside is that you don't really know anything about the "similarity" criteria used to assign the reactivity_ref.
Is that better or worse than reactivity_id?
Or do we just drop this for now?

Should we change reactivity_method and reactivity_readout to free text (from an enum)?

I am fine either way. The benefit of keeping it as an enum is that if we are confident about the enums we have, we can just add more enums over time. This means that the method and readout are more comparable in the short term at the expense of having users not being able to classify the method as they really want to. If we had an "other" enum we could give users a formal way of stating that my reactivity method isn't any of the ones we have in the standard???

2. Should we leave in Reactivity.reactivity_ref

Yes, but as listed currently:
        reactivity_ref:
            type: array
            description: Array of cross references to external receptor/reactivity records
            title: Receptor/reactivity cross-references
            items:
                type: string
            example: ["IEDB_RECEPTOR:10"]
            x-airr:
                nullable: true
                adc-query-support: true

I think this should be pointing to an external epitope record, not an external receptor record, no?
For example, if the Reactivity record in question is for the epitope QKRGIVEQCCTSICS should the reactivity_ref not point to IEDB_EPITOPE:1616345 (https://www.iedb.org/epitope/1616345). The AIRR Reactivity object defines the epitope/antigen/species so it seems to make sense this should link to the IEDB epitope not the IEDB receptor?
Probably a cut and paste error?
The AIRR Receptor object defines a  receptor and points to the IEDB receptor object as it should.
Am I crazy?

Updated reactivity_method and reactivity_readout to be strings with description listing the recommended field values.
Changed Reactivity.reactivity_ref to point to an IEDB Epitope record rather than a IEDB Receptor record.
Cleaned up the examples.

I think the only remaining question is whether we have:

Rearrangement.reactivity_id
Rearrangement.reactivity_ref
Array of one of the above
Neither (no change to Rearrangement)

I think I would lean towards having an array of Rearrangement.reactivity_ref with the spec saying they should be CURIEs that resolve to externally defined entities.

I think I would lean towards having a comma separated list (like v_call) of Rearrangement.reactivity_ref with the spec saying they should be CURIEs that resolve to externally defined entities.

Note that using a CURIE does not preclude referring to an AIRR reactivity record in the ADC in the sense we could in the future define a CURIE for an ADC Reactivity record (e.g: ADC_REACTIVITY:5ed6859e99011334ac05e847).

Have both fields Rearrangement.reactivity_id and Rearrangement.reactivity_ref (CURIE that resolved to external entity e.g. IEDB_RECEPTOR:182992) as comma separated lists.
Order and length of list in one is independent of order and length in the other - need to document this.

Fix "UniProt" camel case to UNIPROT in CURIE.

I believe these changes are done.
@bussec if you can do a quick check that would be good. In particular I removed the IEDB provider, as it was actually not correct. It included only the TCR search, where the JSON response requires both a TCR search and a BCR search to be complete. I don't think there is a way to do this in the spec is there? So I removed the provider in its entirety.

@bussec any comments on the IEDB curie question above? If not, I will merge and close...

From the call:

Merge after adding BCR/TCR urls.

Damn, didn't realize we had to have openapi 3 spec synced in language directories - went around in circles for a while...

Done, created a new issue to review the url field in InformationProvider - #811

Damn, didn't realize we had to have openapi 3 spec synced in language directories - went around in circles for a while...

@bcorrie There is a Makefile now at the top level, do make spec-copy to make your life easier! Likewise with make data-copy if you are updating test data, which is now in a central location and consistent across the languages.


Handle pre-Homestead contract creation when not enough gas

We need this logic in two places: CREATE op code (already there) and Ledger (this PR).

@ntallar there is a FIXME message in Ledger line 116, is it related to this fix?

It seems related. I don't think there are any other changes in Homestead with regard to error handling

It is related, it was just a remainder that the fix from this PR was needed, so it can be removed :+1:

Apart from @AlanVerbner's comment on having tests for this, LGTM!


Maya: Add Maya 2024 and remove pre 2022.

Changelog Description
Adding Maya 2024 as default application variant.
Removing Maya 2020 and older, as these are not supported anymore.
Testing notes:

Launch settings with a new database and validate only Maya 2024-2022 is present.

Split from https://github.com/ynput/OpenPype/pull/5644

Actually - is this missing an update to AYON settings for Maya?

Please add AYON settings changes too.

Code changes look ok. Someone has to validate if we should limit the maya versions to this set. @m-u-r-p-h-y ?

I don't think we support Maya 2018 and with Maya 2020 I would be surprised if there are no issues. Anyway, there's no problem to  define them locally if needed

I agree to have only M2021 and up
if we are touching the defaults I would like to unify the paths for other platforms. We have linux paths defined somewhere but no Mac (not sure what is the default path on MAc though)
something like /Applications/Autodesk/maya2021/Maya.app/Contents/bin/maya ?

if we are touching the defaults I would like to unify the paths for other platforms. We have linux paths defined somewhere but no Mac (not sure what is the default path on MAc though)

Could this be a different PR for another time?

I agree we can tweak the paths in another PR. let's merge this, so it's not festering.


Stacktrace when running jfrog rt go-publish go .

Somehow I get a panic because of the server header split. After some digging it turns out that our artifactory instance was behind a proxy and the server header was overwritten. But anyway this could also have been solved by using the version from the http body. The body is just thrown away to day.
https://github.com/jfrog/jfrog-cli-go/blob/ba45bd3759f592470cb161894dcc77059ced967f/jfrog-client/artifactory/auth/rtdetails.go#L130
# jfrog rt go-publish go --self=false --deps=ALL
[Info] Using go: go version go1.11 linux/amd64

panic: runtime error: index out of range

goroutine 1 [running]:
panic(0x86cda40, 0x18d36028)
	/var/lib/jenkins/tools/org.jenkinsci.plugins.golang.GolangInstallation/go-1.7.1/src/runtime/panic.go:500 +0x331
github.com/jfrog/jfrog-cli-go/jfrog-client/artifactory/auth.(*artifactoryDetails).getArtifactoryVersion(0x18e8a720, 0x0, 0x0, 0x0, 0x0)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/jfrog-client/artifactory/auth/rtdetails.go:130 +0x4f2
github.com/jfrog/jfrog-cli-go/jfrog-client/artifactory/auth.(*artifactoryDetails).GetVersion(0x18e8a720, 0x0, 0x0, 0x0, 0x0)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/jfrog-client/artifactory/auth/rtdetails.go:106 +0x4f
github.com/jfrog/jfrog-cli-go/jfrog-cli/artifactory/commands/golang.Publish(0x18ddd200, 0x18e69765, 0x3, 0xfff5af9e, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/jfrog-cli/artifactory/commands/golang/go.go:27 +0x103
github.com/jfrog/jfrog-cli-go/jfrog-cli/artifactory.goPublishCmd(0x18ddd220)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/jfrog-cli/artifactory/cli.go:1300 +0x44b
github.com/jfrog/jfrog-cli-go/jfrog-cli/artifactory.GetCommands.func30(0x18ddd220)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/jfrog-cli/artifactory/cli.go:416 +0x21
github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli.Command.Run(0x874e150, 0xa, 0x0, 0x0, 0x18d98fd8, 0x1, 0x1, 0x876bf6f, 0x39, 0x8771862, ...)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli/command.go:174 +0xffb
github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli.(*App).RunAsSubcommand(0x18ddd0e0, 0x18ddd040, 0x0, 0x0)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli/app.go:298 +0xe4e
github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli.Command.startApp(0x874755c, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x8755249, 0x14, 0x0, ...)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli/command.go:249 +0x56a
github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli.Command.Run(0x874755c, 0x2, 0x0, 0x0, 0x0, 0x0, 0x0, 0x8755249, 0x14, 0x0, ...)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli/command.go:65 +0x71
github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli.(*App).Run(0x18ddc780, 0x18d0a2d0, 0x6, 0x6, 0x0, 0x0)
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/vendor/github.com/codegangsta/cli/app.go:187 +0xd98
main.main()
	/var/lib/jenkins/workspace/EcoSystem/jfrog-cli-release/temp/src/github.com/jfrog/jfrog-cli-go/jfrog-cli/jfrog/main.go:81 +0x23a
# jfrog --version
jfrog version 1.20.2

Thanks @erikthorselius for reporting this. We will change this in the upcoming releases to get the information from the body.

Hi @erikthorselius I wanted to update you that this commit resolved this issue.
This was already released with the latest CLI (version 1.23.2).
We will appreciate your feedback.

Thanks for the follow up!


Default "null" argument. Wrong generation.

Hello.
https://github.com/mono/VulkanSharp/blob/a83bcbe17876ab5fd8147ae865b38164a4462387/src/Vulkan/Handles.cs#L1612
You can see in this case, that default argument has "null" value, but then try take fence's member: fence.M that throw  NullPointerException(line 1621).
And some methods with same signature will throw NullPointerException too.

It seems like to use VK_NULL_HANDLE, one should use the default constructor (i.e. new Fence()) in VulkanSharp

Yes, I can use default constructor for fency, but it's looking strange to have default param "null" in this case.
So if i don't have another way to use, for example, Queue.Submit, i think default argument should be removed or generator should be changed.

Queue.Submit should now work OK with default null value


Video playing issue

Describe your problem here.
Im trying to add videos to the sound test menu (maybe cutscenes later) and I tried to use the 2.0 source code because that uses videos, when i tried to add a sound test video, it says this:
MP4Handler has no field playMP4
the code from 2.0:
Are you modding a build from source or with Lua?
Source
What is your build target?
Windows
Did you edit anything in this build? If so, mention or summarize your changes.
yes

Sorry I accidently posted the issue without the code
so here it is the sound test video from 2.0:
else if (first == 23 && second == 23)
{
var video:MP4Handler = new MP4Handler();
woahmanstopspammin = false;
flashyWashy(true);
new FlxTimer().start(2, function(tmr:FlxTimer)
{
flashyWashy(false);
FlxG.sound.music.stop();
			});
			new FlxTimer().start(2.1, function(tmr:FlxTimer)
			{
            	video.playMP4(Paths.video('soundtestvideoname'));
				incameo = true;
			});

it's playVideo not playMP4

it's playVideo not playMP4

ok, it works now, thank you!

np


B.3 Code Snippet not rendering

 not rendering on GH, but showing in preview mode with VSCode.

Also not working right in https://github.com/SMPTE/html-pub/pull/187


ci: buildless ecosystem ci

By using the --commit option in vite-ecosystem-ci, we can leverage the already built versions of vite in pkg.pr.new!
Here, after sending the ecosystem comment, we'll check if there's an already built version, if not, we'll try triggering a build. The  🚀 reaction is a sign that the build is happening and we should wait until it's done.
After that, the normal process continues.

/ecosystem-ci run

As far as I know this tests the previous version of vite-ecosystem-ci
rather than the new one.
Which makes it requires a merge.
On Tue, 5 Nov 2024, 13:43 vite-ecosystem-ci[bot], @.***>
wrote:

⏳ Triggered ecosystem CI: Open
https://github.com//vitejs/vite-ecosystem-ci/actions/runs/11681487209
—
Reply to this email directly, view it on GitHub
https://github.com/vitejs/vite/pull/18525#issuecomment-2456696460, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AJBMICDQVZRRLA6YQFS6JPLZ7CHMDAVCNFSM6AAAAABQ5A7JXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJWGY4TMNBWGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Thank you for for merging
On Tue, 10 Dec 2024, 05:51 sapphi-red, @.***> wrote:

Merged #18525 https://github.com/vitejs/vite/pull/18525 into main.
—
Reply to this email directly, view it on GitHub
https://github.com/vitejs/vite/pull/18525#event-15593329743, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AJBMICEBRH7R4BRLADW4IFT2EZFZHAVCNFSM6AAAAABQ5A7JXWVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJVGU4TGMZSHE3TIMY
.
You are receiving this because you authored the thread.Message ID:
@.***>


IMU Update

Draft PR for reviewing code

@Annika-wyt, can you resolve the conflicts then I will merge


Nextjs module not found: Can't resolve 'the-supersonic-plugin-for-scroll-based-animation'

Hello, this plugin is great, but I have a problem and can't import the plugin
I'm using nextjs, below is the code
import {
 TheSupersonicPlugin,
} from 'the-supersonic-plugin-for-scroll-based-animation';

 new TheSupersonicPlugin([
 {
 start: '.start',
 end: '.end',
 elements: ['.animatable-element'],
 },
 ]);

What is the reason? I have installed the plug-in correctly.
Thanks.

Build Error
Failed to compile

Module not found: Can't resolve 'the-supersonic-plugin-for-scroll-based-animation'
  1 | import { useTranslations } from 'next-intl';
  2 | import Container from 'react-bootstrap/Container';
> 3 | import { TheSupersonicPlugin } from 'the-supersonic-plugin-for-scroll-based-animation';
    | ^
  4 |
5 | const plugin = new TheSupersonicPlugin([
  6 |   {

Hi, that is the error code, thanks.

@aboutjquery it looks like you haven't installed the plugin via npm install the-supersonic-plugin-for-scroll-based-animation --save-dev

@aboutjquery it looks like you haven't installed the plugin via npm install the-supersonic-plugin-for-scroll-based-animation --save-dev

I have already installed
"the-supersonic-plugin-for-scroll-based-animation": "^2.1.0"
I have no idea why its happen.

@aboutjquery i'm not super familiar with nextjs, but if you can locate the-supersonic-plugin-for-scroll-based-animation in your node_modules folder, a possible reason maybe is that nextjs tries to execute plugin in SSR mode and it fails, because plugin relies on browser API, which is not available in SSR mode. I would try to import plugin dynamically like here.
Please return with an answer if it helps.

@aboutjquery i'm not super familiar with nextjs, but if you can locate the-supersonic-plugin-for-scroll-based-animation in your node_modules folder, a possible reason maybe is that nextjs tries to execute plugin in SSR mode and it fails, because plugin relies on browser API, which is not available in SSR mode. I would try to import plugin dynamically like here.
Please return with an answer if it helps.

Thanks and sorry for my late reply, I am using SSG now, and I tried:

const TheSupersonicPlugin = dynamic(
  () =>
    import('the-supersonic-plugin-for-scroll-based-animation').then(
      (mod) => mod.TheSupersonicPlugin,
    ),
  { ssr: false },
);

Error report
Module not found: Can't resolve 'the-supersonic-plugin-for-scroll-based-animation'
  14 | const TheSupersonicPlugin = dynamic(
  15 |   () =>
> 16 |     import('the-supersonic-plugin-for-scroll-based-animation').then(
     |     ^

I am no idea why its happen.


Comparison with updated Based

Based architecture seems to have been updated - https://arxiv.org/abs/2402.18668. Any insights into how it compares with Rebased?

From this point, the updated arxiv version of Based is more like subsequent research on subquadratic architectures rather than a simple upgrade. This new version introduces combined linear and sliding window attention, which is orthogonal to selecting a linear attention kernel studied with our paper. Right now, we do not have evaluations of a rebased kernel combined with sliding window attention.


Delete canary feature

Currently, it supports multiple procfiles and different images, so custom services and HTTPRoutes can be used.
See: #48
Canary is no longer necessary, so we plan to remove this feature in the future.
Involving the following projects:

[x] https://github.com/drycc/controller
[x] https://github.com/drycc/controller-sdk-go
[x] https://github.com/drycc/workflow-cli

complete


fix: requeue message

It seems that there is no need to copy here, If you need to regenerate a message object here you should use deepcopy.

Codecov Report

Merging #154 (62ab3c2) into develop (e66f3aa) will increase coverage by 3.34%.
The diff coverage is 80.40%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@             Coverage Diff             @@
##           develop     #154      +/-   ##
===========================================
+ Coverage    67.62%   70.96%   +3.34%
===========================================
  Files           37       42       +5
  Lines          942     1295     +353
===========================================
+ Hits           637      919     +282
- Misses         305      376      +71

Impacted Files
Coverage Δ

taskiq/abc/middleware.py
100.00% <ø> (ø)

taskiq/abc/result_backend.py
100.00% <ø> (ø)

taskiq/cli/scheduler/run.py
0.00% <0.00%> (ø)

taskiq/cli/watcher.py
0.00% <ø> (ø)

taskiq/cli/worker/log_collector.py
100.00% <ø> (ø)

taskiq/cli/worker/process_manager.py
0.00% <0.00%> (ø)

taskiq/cli/worker/run.py
0.00% <0.00%> (ø)

taskiq/events.py
100.00% <ø> (ø)

taskiq/receiver/params_parser.py
96.87% <ø> (ø)

taskiq/result_backends/dummy.py
100.00% <ø> (ø)

... and 23 more

... and 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Connection URL support for Cluster constructor

Problem
Currently the Cluster constructor cannot take a url string as input. Therefore the user has to manually parse a url string obtained from the runtime environment into a structured argument which the ioredis.Cluster understands.
Desired Behaviour
It would save a lot of repetitive and error-prone work if the library itself takes care of the parsing.

The only blocker I can think of for this is to find a URI spec for multi-endpoint.

@luin I believe a single endpoint url can be used to access a cluster. Multi-endpoint url spec and url parsing for cluster are related but not entirely overlapping.


Update index.md

17/11/21 12:47

:x: Validation status: errors

File
Status
Preview URL
Details

:x:Error

Details

Line 128: [Error] Pull content in folder W:\cmfh-s_themes failed. Error: remote: Repository not found. fatal: repository<EMAIL_ADDRESS>not found
[Warning] Cannot find docset information for repository: 75fec881-80a1-e544-ae48-ccbac7e8c3d4 and docset name: Docset1. Please make sure the docset is correctly provisioned

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Add environment variables for logging level

Proposed changes
This PR adds environment variables for logging level.
Types of changes
What types of changes does your code introduce to the project: Put an x in the boxes that apply

[ ] Bugfix (non-breaking change which fixes an issue)
[X] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Update only documentation, not any source code.

Checklist
Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of
them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before
merging your code.

[X] I have read the CONTRIBUTING doc
[ ] I have signed the CLA
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added necessary documentation (if appropriate)
[ ] Any dependent changes have been merged and published in downstream modules

Further comments
N/A

Codecov Report

Merging #60 (dbf9c5f) into main (44269c2) will increase coverage by 0.21%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #60      +/-   ##
==========================================
+ Coverage   83.04%   83.26%   +0.21%
==========================================
  Files           2        2
  Lines         690      699       +9
==========================================
+ Hits          573      582       +9
  Misses        117      117

Impacted Files
Coverage Δ

lets-fiware.sh
82.13% <ø> (ø)

config.sh
100.00% <100.00%> (ø)

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 44269c2...dbf9c5f. Read the comment docs.


API Version only displayed when cargo runs

The API version is only displayed when cargo runs.

Fixed in #162


#14 Standardize gmelius endpoint

Pull request for the topic https://github.com/slingr-stack/gmelius-endpoint/issues/14 created by @agreggio-slingr
What does it do?
This ticket implements the use of slingr-helpgen, whereby it modifies existing functions, adds basic functions and step flows.
How to test it?
Make calls from the platform for example using the console using the information provided in the documentation.
Implementation notes
Create new version of the endpoint, it is not compatible with previous versions.
Implementation notes
Create a new tags changing the major version and deploy to the platform.

#approve

Version for implementation tag created: v2.2.1


Added selection detection to place markers

Currently, if you have multiple scribe instances on a page and call selection.placeMarkers() each scribe instance will place markers around the current selection irrespective of whether that selection is within it's element. This causes multiple markers to be placed.
This PR adds a check to see if the current selection is within a scribe instances element. If not, it bails out.

Looking good :+1:  Maybe commenting this a bit more would help for the future though, as it might not be immediately apparent why we need to do this.

Maybe there's an issue we could refer to as well?

@robinedman @theefer This should now work and actually make sense.

Nice fix! :+1:

:+1:  Too, though maybe we should add unit tests for it so we don't break it in the future? Could be done separately though.

Very difficult to unit test this so I wouldn't bother...
On 23 January 2015 at 12:08, Robin Edman<EMAIL_ADDRESS>wrote:

[image: :+1:] Too, though maybe we should add unit tests for it so we
don't break it in the future? Could be done separately though.
—
Reply to this email directly or view it on GitHub
https://github.com/guardian/scribe/pull/324#issuecomment-71184896.

--

Visit theguardian.com. On your mobile and tablet, download the Guardian
iPhone and Android apps theguardian.com/guardianapp and our tablet editions
theguardian.com/editions.  Save up to 57% by subscribing to the Guardian
and Observer - choose the papers you want and get full digital access.
Visit subscribe.theguardian.com
This e-mail and all attachments are confidential and may also be
privileged. If you are not the named recipient, please notify the sender
and delete the e-mail and all attachments immediately. Do not disclose the
contents to another person. You may not use the information for any
purpose, or store, or copy, it in any way.  Guardian News & Media Limited
is not liable for any computer viruses or other material transmitted with
or as part of this e-mail. You should employ virus checking software.
Guardian News & Media Limited is a member of Guardian Media Group plc. Registered
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered
in England Number 908396

Initially I tried to add tests but as @hmgibson23 points out it's particularly difficult. You could add tests to composer @nealmadlani ?

@hmgibson23 @robinedman @theefer any idea why the scribe tests would fail to start in firefox. I seem to get this problem even on master using my local machine.

Outdated Selenium?
On 23 January 2015 at 12:15, Jon Parsons<EMAIL_ADDRESS>wrote:

@hmgibson23 https://github.com/hmgibson23 @robinedman
https://github.com/robinedman @theefer https://github.com/theefer any
idea why the scribe tests would fail to start in firefox. I seem to get
this problem even on master using my local machine.
—
Reply to this email directly or view it on GitHub
https://github.com/guardian/scribe/pull/324#issuecomment-71185583.

--

Visit theguardian.com. On your mobile and tablet, download the Guardian
iPhone and Android apps theguardian.com/guardianapp and our tablet editions
theguardian.com/editions.  Save up to 57% by subscribing to the Guardian
and Observer - choose the papers you want and get full digital access.
Visit subscribe.theguardian.com
This e-mail and all attachments are confidential and may also be
privileged. If you are not the named recipient, please notify the sender
and delete the e-mail and all attachments immediately. Do not disclose the
contents to another person. You may not use the information for any
purpose, or store, or copy, it in any way.  Guardian News & Media Limited
is not liable for any computer viruses or other material transmitted with
or as part of this e-mail. You should employ virus checking software.
Guardian News & Media Limited is a member of Guardian Media Group plc. Registered
Office: PO Box 68164, Kings Place, 90 York Way, London, N1P 2AP.  Registered
in England Number 908396

Kinda looks likeinitializeScribe isn't firing... I'm totally stumped, you don't get any output in the FF console.

You could try downgrading FF


Change commit user name

What type of PR is this? (check all applicable)

[ ] Refactor
[ ] Feature
[ ] Bug Fix
[ ] Optimization
[x] Content Update

Category

[ ] zopen framework
[ ] Documentation
[x] CI/CD
[ ] Tools

Description

Related Issues

Related Issue #
Closes #

[optional] Are there any post-deployment tasks or follow-up actions required?

@IgorTodorovskiIBM when you can spare a few mins, please review.

@IgorTodorovskiIBM when you can spare a few mins, please review.

Do you know if the commit user name needs to match a github id? We still use https://github.com/zosopentoolsmain. We could probably rename it to zopenmain or zopencommunitymain

It used to work with the non-existent bump. Raising this as just a chore; doesn't really need fixing.
https://github.com/zopencommunity/meta/pull/437


TogetherAI compatibilty?

TogetherAI has a openai compatibility api. It allows for simple plug and play with the openai module in python. However, after setting up the .env file as shown below, i get the following error
OpenAI API failed with status: 401 error: Incorrect API key provided:
sk-vxLAE***************************************tBZb. You can find your API key
at https://platform.openai.com/account/api-keys.'}]}, 'status': 'FAILED'}
Now I simply put my .env file in my $HOME directory and I am running verba start from the same directory too. Am I missing something?
.env
OPENAI_API_KEY=TOGETHERAI_KEY
OPENAI_BASE_URL=https://api.together.xyz/v1
OPENAI_MODEL=meta-llama/Llama-3-70b-chat-hf
AZURE_OPENAI_EMBEDDING_MODEL=WhereIsAI/UAE-Large-V1

You should create new generator file and should not use openai library. Use together python library instead.
https://docs.together.ai/docs/inference-python


UDP in passive receive mode sums in +IPD the sizes of pending messages.

Environment

Development Kit:      Wemos D1 mini 4MB flash
Module or chip used:  ESP-12
esp-at version:  v<IP_ADDRESS>-rc1_esp8266-4-g51262c8

Problem Description
UDP in passive receive mode sums in +IPD the sizes of pending messages. This makes it impossible to read the individual messages.
Expected Behavior
+IPD in passive mode should report the size only of the next pending UDP message.
Steps to repropduce

setup the AT firmware with AT+CIPRECVMODE=1
start UDP listener AT+CIPSTART="UDP","<IP_ADDRESS>",2390,2390,2
send 3 different UDP messages to the IP of the AT firmware, (best from different IP addresses)
read with with AT+CIPRECVDATA the messages with sizes reported by +IPD

Debug Logs
WIFI CONNECTED
WIFI GOT IP
AT+CIPRECVMODE=1

OK
AT+CIPDINFO=1

OK
AT+CIPSTART="UDP","<IP_ADDRESS>",2390,2390,2
local port:2390

change type:2

CONNECT

OK

+IPD,41
AT+CIPRECVDATA=41
to read 41 bytes

+CIPRECVDATA:41,"<IP_ADDRESS>",40406,this is a test message from <IP_ADDRESS>
OK

+IPD,41
AT+CIPRECVDATA=41
to read 41 bytes

+CIPRECVDATA:41,"<IP_ADDRESS>",46298,this is a test message from <IP_ADDRESS>
OK

+IPD,82
AT+CIPRECVDATA=82
to read 82 bytes

+CIPRECVDATA:82,"<IP_ADDRESS>",46007,this is a test message from <IP_ADDRESS>this is a test message from <IP_ADDRESS>
OK

I think a simplest fix would be to return only one UDP message even if +CIPRECVDATA requests larger size (because the host doesn't know the size of the next message if +IPD reported a sum of pending messages size)

this is almost fixed in 2.2.
a +IPD for a message is now reported only after the previous message was read. an AT+CIPRECVDATA  gets the content of one message only. this is OK.
but if the requested length is smaller then the size of the message, the rest of the message is lost.. this can happen for a large message if the host can't allocate one large buffer.

May I know if there is any update? If the issue still exists, please let us know.

so it is same as it was in 2.2. a message must be read at once in passive mode
+IPD,4,81

>>Send to /dev/ttyACM0: "AT+CIPRECVLEN?"<<
AT+CIPRECVLEN?
+CIPRECVLEN:-1,-1,-1,-1,81

OK

>>Send to /dev/ttyACM0: "AT+CIPRECVDATA=4,32"<<
AT+CIPRECVDATA=4,32
+CIPRECVDATA:32,12345678901234567890123456789012
OK

>>Send to /dev/ttyACM0: "AT+CIPRECVLEN?"<<
AT+CIPRECVLEN?
+CIPRECVLEN:-1,-1,-1,-1,0

OK

I confirm the problems reported by JAndrassy. Currently, if multiple UDP messages (datagrams) are received there is no way of separating them from each other. Separating UDP datagrams is a strict requirement for any UDP application, unlike TCP (which is a stream protocol).
The best solution is:

+IPD and +CIPRECVLEN in passive mode must report the size only of the next pending UDP message.
+CIPRECVDATA must return only one UDP message if +CIPRECVDATA requests a size that is larger or equal to the size of the next pending UDP message.

@ds-c 1) a 2) are true since version 2.2. for passive mode

@JAndrassy, unfortunately my tests show that 1) and 2) are not implemented.

Module or chip used: ESP-12
esp-at version: ESP8266-IDF-AT_V<IP_ADDRESS>

ATE0
> OK

AT+CIPMUX=0
> OK

AT+CIPDINFO=0
> OK

AT+CIPRECVMODE=1
> OK

AT+CIPSTART="UDP","<IP_ADDRESS>",2390,2390,2
> CONNECT
> OK

Send UDP message "0123" to the module:
> +IPD,4
Send UDP message "456" to the module.
Send UDP message "78" to the module.
Check the size of the next pending UDP message:
AT+CIPRECVLEN?
> +CIPRECVLEN:9
> OK

Expected: the reported size is the size of the next pending message (4)
Actual: the reported size is the size of all pending messages (9)
Receive the next pending message:
AT+CIPRECVDATA=4
> +CIPRECVDATA:4,0123
> OK
> +IPD,5

Expected: the size reported by IPD is the size of the next pending message (3)
Actual: the size reported by IPD is the size of all pending messages (5)
Receive the next pending message:
AT+CIPRECVDATA=100
> +CIPRECVDATA:5,45678
> OK

Expected: only the next pending message is read ("456")
Actual: all pending messages are read ("45678")
So it is impossible to check the size of the next pending UDP message and receive messages separately one by one, as required by UDP applications.


flatten command - fix wrong Title and Description values

fix for the problem mentioned in: #463
flattening of Title and Description:
The Title and Description fields are set to the value specified in the base schema.
If the base schema does not contain any values, the first value from the 'allOf' property is used instead.

Codecov Report
Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (593bd07) 83.76% compared to head (132898e) 83.75%.

Files
Patch %
Lines

flatten/merge_allof.go
76.92%
2 Missing and 1 partial :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #464      +/-   ##
==========================================
- Coverage   83.76%   83.75%   -0.01%
==========================================
  Files         217      217
  Lines       12550    12561      +11
==========================================
+ Hits        10512    10520       +8
- Misses       1663     1665       +2
- Partials      375      376       +1

Flag
Coverage Δ

unittests
83.75% <76.92%> (-0.01%)
:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


fix: remove CVE-2023-46809 revert config

revert https://github.com/cnpm/cnpmcore/pull/650
run test on Node.js 22

Summary by CodeRabbit

Chores

Updated Node.js version support to 18, 20, and 22.
Removed unnecessary configuration from the release workflow.
Cleaned up outdated security-related entries in the package configuration.

看起来不简单

https://github.com/travist/jsencrypt/issues/84


APP first launch slow in MacOS

MacOS system, the first time to launch the APP is particularly slow, the icon will jump in the Dock for about 5 seconds before the APP will open.

First, hello (don't forget we're humans).
Then, it doesn't seems to be a problem that depends on my code.
If the app you've built using electron packager is slow to open on the first launch, it seems to be an architecture problem with Electron packager. Your Mac seems to convert your app using Rosetta on the first launch.
Do you have a M1/M2 Mac and use the command line written in README.md file or $ npm run package-mac?
$ npx electron-packager . --overwrite --platform=darwin --arch=x64 --icon=assets/icons/mac/icon.icns --prune=true --out=release-builds

In this case, don't use --arch=x64 but use --arch=arm64 instead (see https://electron.github.io/electron-packager/main/modules/electronpackager.html#officialarch).
You won't build an Electron app for Intel processors (x64) but for M1/M2 processors, and your Mac won't convert your x64 architecture app to arm64 architecture on first launch.