UseNLog vs AddNLog

I'm trying to figure out what's the difference between such registrations of NLog:
One:
       WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .ConfigureLogging(logging =>
        {
            logging.ClearProviders();
            logging.SetMinimumLevel(Microsoft.Extensions.Logging.LogLevel.Trace);
        })
        .UseNLog();

Two:
        WebHost.CreateDefaultBuilder(args)
        .ConfigureLogging(
            logging =>
            {
                logging.ClearProviders();
                logging.SetMinimumLevel(Microsoft.Extensions.Logging.LogLevel.Trace);
                logging.AddNLog("path");
            }
        );

According to doc I should use first one. For both cases I tried to check how services registered, and when instances are added to service collection, but didn't found the answer. Could you please explain why first one is recommened and what is the defference between registrations?

Originally the AddNLog was only available for ILoggerFactory, which only registered NLog as LoggingProvider. But FAILED to hook up all the ${aspnet}-layoutrenderers.
To correctly register NLog as LoggingProvider AND hook up ${aspnet}-layoutrenderers. Then one had to call UseNLog().
Later in time then ILoggingBuilder was introduced with AspNetCoreV2. This suddenly allowed AddNLog to also work correctly like UseNLog (Because ILoggingBuilder gave access to the dependency injection system).
With NLog.Web.AspNetCore ver. 4.0 then both both ILoggingBuilder.AddNLog and IHostBuilder.UseNLog will work just fine. So now it is up to the user which style feels right.

I investigated up to level of BuildCommonServices() execution and found out that same services are registered for both variants. So, my theory is confirmed.
Many thanks, now it's clear


Filter by audit status report

Trello card
User need
As a content auditor..
I need filter the audit progress tab and csv export by audit status
So that I can efficiently prioritise audited items for improvement
Background
This has been requested by HMRC. At present they can filter the audit progress report (and therefore the csv export) by Assigned to, Organisation(s) and Content type
This allows them to download a csv but currently the file contains all audited and unaudited items, which is an unmanageably long list to review. Viewing audited items and unaudited items separately would be much more useful
Before

After

 (3) Filter the export by audit status


Can't override tokenSeparators set to defaults

https://jsbin.com/kibipakivu/1/edit?html,js,output
As you can see, tokenSeparators is set to select2.defaults. If you then want to override that on the actual select2 instance, the separators will be merged and not overridden.
You can easily test that, by going to supplied jsbin and start typing in select box. You can then use space or comma and new tag will be added, even though the separators were supposed to be reset to default [].

 $('#example1').select2({
  tags: true,
  tokenSeparators: null,
});

This is one of those weird edge cases where how we apply defaults using $.extend comes into play, specifically because we are using a recursive deep copy. When a recursive deep copy is used for an array, it will overwrite the array contents if there is a conflict (so the contents differ) but if one side is empty, it will just merge it. This is the behaviour you're seeing here, since the two arrays are getting merged and the default is being maintained.
> $.extend({a:[1]},{a:[]})
< {a: Array(0)}
> $.extend(true, {a:[1]},{a:[]})
< {a: Array(1)}

You can work around this by setting the value to null which will overwrite the array set in the defaults and do what you're expecting.
> $.extend(true, {a:[1]},{a:null})
< {a: null}

Select2 specifically treats null and [] the same for array values for this reason (and because it makes defaults way easier to set). As a result, I'm going to close off this ticket as not a bug, but I am willing to review pull requests for the documentation to improve it to make this more clear. We don't have a ton of array options so there aren't a lot of places where this will be an issue.

Thanks for the explanation.
What confused me is that the docs state that the default for tokenSeparators is []. So I expected if I use the default value I would get the default result.

So I expected if I use the default value I would get the default result.

Good catch! That actually makes a lot of sense and it's unfortunate that $.extend doesn't work the way you or I would have expected it. I think the easy "fix" for this would be to update the documentation to reflect null being the actual default value for tokenSeparators, similar to how that is the default for data.
Interested in making a pull request for that?

I just opened a PR for it.


Countries param mandatory

https://github.com/placekit/api/pull/46

Just updated READMEs and examples, don't want to force the option on methods so the developer can choose when and how to define it.


Patch source change upstream to absei/abseil-cpp

We currently have a few source level patch that ideally should be upstreamed to abseil/absei-cpp if posssible.

https://github.com/firebase/abseil-cpp-SwiftPM/pull/9

Merged #9


feature: Allow passing properties to encapsulated webview - if so, deep linking can be supported

Dear Authors, Contributors
By using Your package to consume dynamic content that is displayed to users, a new requirement raised to make buttons rendered within the WaveCX webview deep link compatible - in other words, if a WaveCX contains a button that could be redirected within the mobile application, then it should be redirected. If not, the handling remains as is.
Now, to implement such capability, I need your help/advise:

Would it be possible to pass properties to the underlying WebView component of yours? I'm interested in webivew's onShouldStartLoadWithRequest property. With the help of it, the mobile application could intercept the outgoing request and decide if it should be redirected or allowed to load by the webview. If the adjustment is applied to the package, no client-side patching is required.
Once the redirection is done, the WaveCX modal remains opened covering the underneath screen. To close it, session-ended event have passed to the handleEvent of useWaveCx hook. Is that a correct approach?

Demo of the feature can be found here:
https://github.com/user-attachments/assets/e4a55d5f-29d2-4cec-911d-1835a6d3b300
Suggested Diff (as I couldn't raise a PR):
git diff
diff --git a/src/index.tsx b/src/index.tsx
index 3834198..cd482bf 100644
--- a/src/index.tsx
+++ b/src/index.tsx
@@ -18,7 +18,7 @@ import {
   Text,
   View,
 } from 'react-native';
-import WebView from 'react-native-webview';
+import WebView, { type WebViewProps } from 'react-native-webview';

 import {
   composeFireTargetedContentEventViaApi,
@@ -58,6 +58,7 @@ export const WaveCxProvider = (props: {
   children?: ReactNode;
   apiBaseUrl?: string;
   recordEvent?: FireTargetedContentEvent;
+  webviewProps?: WebViewProps;
 }) => {
   const recordEvent = useMemo(
     () =>
@@ -260,6 +261,7 @@ export const WaveCxProvider = (props: {
             )}

             <WebView
+              {...props.webviewProps} //! Won't be able to override below props like source, ref, style etc. Verify if override of below props should be supported. If so or just partially, consume the props.
               source={{ uri: activeContentItem.viewUrl }}
               ref={webViewRef}
               style={{
@@ -274,6 +276,9 @@ export const WaveCxProvider = (props: {
                   webViewRef.current?.stopLoading();
                   Linking.openURL(event.url);
                 }
+
+                //! Example of supporting custom props partially where desired.
+                props.webviewProps?.onNavigationStateChange?.(event);
               }}
             />
           </>

Sincerely,

Once the redirection is done, the WaveCX modal remains opened covering the underneath screen. To close it, session-ended event have passed to the handleEvent of useWaveCx hook. Is that a correct approach?

@av185218 I believe the session-ended event should only be triggered during logout, since starting a session is triggered upon user authentication only.

Thank you @SG185511.
In that case, a way should be identified how the inner modal of WaveCX provider can be closed from outside.

@av185218 a PR is in for this at https://github.com/WaveCX/wavecx-react-native/pull/8. The proposed interface can be seen at https://github.com/WaveCX/wavecx-react-native/tree/feat/link-callbacks?tab=readme-ov-file#intercepting-links.
Instead of allowing direct props for the web view component we decided that a more opaque interface specifically for handling links within content was more appropriate.
Does this look like it should work for your use case?

@jonathanraftery changes looks great, soon I will try them out and follow up. Closing the issue, thank you!

@jonathanraftery Works like a charm, thank you for the support!


AAQ should filter KubeVirt virt-exportserver pods?

Is your feature request related to a problem? Please describe:
A clear and concise description of what the problem is.
AAQ should probably filter virt-exportserver pods since they are created/managed by KubeVirt
Describe the solution you'd like:
A clear and concise description of what you want to happen.
Describe alternatives you've considered:
A clear and concise description of any alternative solutions or features you've considered.
Additional context:
Add any other context or screenshots about the feature request here.

@mhenriks thanks for raising this


No error message populated on NerdGraphRequest event when we purposefully broke API key environment variable [dev]

Summary
Error events are being sent, but the errorMessage attribute / field is empty. Looking at the code, its because we are sending the entire error object, rather than error.message. So this is a fairly simple fix that needs to happen in two places: the catalog page, and the quickstart details page.
Acceptance Criteria

[x] Events have populated error messages

@nr-kkenney can you link your PR to this ?

I assume we can close this out with out merging the PR given our decision is not to release SSR, can you confirm if that is true @nr-kkenney ?

@jpvajda yep. we can close this out.


Allow empty patch in upstream script

This pull request allows us to have an empty patch file in such cases as https://github.com/pulumi/pulumi-pagerduty/pull/543, where all we need the submodule for is to make up for a lack of proper Go module versioning in an upstream provider.
This change is a minimal change to the script and setup, and we won't have to add additinal logic to ci-mgmt.yaml configs.

Allow empty patch for upstream apply
Make test workflows

Please do a test run to ensure that --allow-empty works as expected. Otherwise LGTM.

It's already applied in pulumi-vault and pulumi-pagerduty (linked above). A local run against pulumi-gcp (which has non-empty patches) shows make upstream works as expected. Merging.


Incorrect number counts of galaxy pairs on large scale(s>10Mpc)

Incorrect number counts of galaxy pairs on large scale(s>10Mpc)
I am working on galaxy clusterings on the scale less than around 60Mpc, I use my own Fortran code to perform the pairs countings before I found Corrfunc. The Corrfunc is super faster than my codes, so I decide to use Corrfunc. To make sure I get the same results for the same sample by using different codes, I made a check. For a galaxy sample and its corresponding random sample, I calculated the projected two-point correlation function using both the Corrfunc and my own codes,  and wp(r_p) derived from different codes are slightly different. In order to find which codes give the incorrect wp(r_p), I compared the galaxy-galaxy pair counts derived from the two codes, and I found that the number of pairs from two codes is different in large r bins, as shown below:
Corrfunc:
import numpy as np
from Corrfunc.theory.DD import DD
gdata=np.loadtxt("galaxy_xyz.dat")
X=gdata[:,0]
Y=gdata[:,0]
Z=gdata[:,0]
nthreads=50
aa=np.linspace(-2.,1.8,20)
bins=10.**aa
autocorr=1
DDn=DD(autocorr,nthreads,bins,X,Y,Z,output_ravg=True)
The DDn given by Corrfunc is :
0.010000   0.015849   0.012379       1172   0.000000
0.015849   0.025119   0.020728        768   0.000000
0.025119   0.039811   0.032174        774   0.000000
0.039811   0.063096   0.051028       1138   0.000000
0.063096   0.100000   0.082221       1874   0.000000
0.100000   0.158489   0.129879       3406   0.000000
0.158489   0.251189   0.206134       6074   0.000000
0.251189   0.398107   0.327142      11594   0.000000
0.398107   0.630957   0.517950      22354   0.000000
0.630957   1.000000   0.820258      41492   0.000000
1.000000   1.584893   1.297674      74738   0.000000
1.584893   2.511886   2.066595     135258   0.000000
2.511886   3.981072   3.292980     291080   0.000000
3.981072   6.309573   5.253221     749496   0.000000
6.309573  10.000000   8.345029    2165098   0.000000
10.000000  15.848932  13.260500    6766712   0.000000
15.848932  25.118864  21.053047   22450646   0.000000
25.118864  39.810717  33.392555   77411296   0.000000
39.810717  63.095734  52.798855  257952048   0.000000
By using my code, the pair counts of "galaxy_xyz.dat" are:
     1172.0000000000
<PHONE_NUMBER>000
<PHONE_NUMBER>000
     1138.0000000000
     1874.0000000000
     3406.0000000000
     6074.0000000000
    11594.0000000000
    22354.0000000000
    41492.0000000000
    74738.0000000000
<PHONE_NUMBER>000000
<PHONE_NUMBER>000000
<PHONE_NUMBER>000000
  2165098.0000000000
  6766682.0000000000
 22450214.0000000000
 77405384.0000000000
257859458.0000000000

I have also counted the pairs using other methods, say, the astroML BallTree() function and the simple two-loop pair counting, the numbers of pairs given by all these two methods are the same as results of my code. So, it seems Corrfunc.theory.DD() gives the incorrect numbers in bins of r>10Mpc, or  maybeI used Corrfunc.theory.DD() in the wrong way. Any suggestions? Thanks!!!

Hi, thanks for the report!  It looks like you did not specify boxsize as an argument in your call to Corrfunc.theory.DD, so the code will try to infer a periodic domain from the extent of the particle distribution.  So if the particles are in a box of 500 Mpc but the particles only span 498 Mpc, then the pair counts will be incorrect on large scales.  If you run with verbose=True, you will see the inferred box size.  Can you manually specify the boxsize and try again?
More info on boxsize here: https://corrfunc.readthedocs.io/en/master/api/Corrfunc.theory.html#module-Corrfunc.theory.DD
@manodeep I am in favor of removing automatic boxsize detection due to issues like this.

Cool! Thanks for reply! I just set periodic=False and Corrfunc.theory.DD() gives the correct number counts!!! I really appreciate your help!!

@LeiAstro Looks like your issue is resolved - is it okay to close this issue?
@lgarrison I am fine with requiring boxsize when periodic==True. Is that what you were thinking?

Sure!! Thanks!!

@LeiAstro Great - thanks!

Sorry, but I have a quick question on this closed issue. When I use "from Corrfunc.theory import DDrppi" to count pairs to measure the wp by "convert_rp_pi_counts_to_wp" function, I still got a slightly different value for each rp bins. I am wondering the definition of the line-of-sight vector in Corrfunc, do you use (1)middle-point of two galaxies? (e.g., Fisher, K. B., Davis, M., Strauss, M. A., Yahil, A., & Huchra, J. 1994, MNRAS, 266, 50) (2) end-point line-of-sight? (3) Angular bisector? I haven't found any info on this in the corrfunc docs. Thanks!!!

@LeiAstro The convention in Corrfunc is from Fisher et al (1994). You can find more details in the docs here

Many thanks!!!


"WPA3 Enterprise" / "WPA2/3 Enterprise (mixed)" in Wireless configuration

I'm missing "WPA3 Enterprise" / "WPA2/3 Enterprise (mixed)" in Wireless configuration on Luci.
It is already implemented according to https://openwrt.org/docs/guide-user/network/wifi/basic
Steps to reproduce:

Install https://downloads.openwrt.org/releases/19.07.0-rc1/targets/ipq806x/generic/openwrt-19.07.0-rc1-ipq806x-generic-tplink_c2600-squashfs-sysupgrade.bin on Archer C2600, disabled "Keep settings and retain the current configuration"
Set password via Luci
Connect via SSH:

root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg remove wpad-basic
root@OpenWrt:~# opkg install wpad-openssl
root@OpenWrt:~# reboot

Login via Browser
Goto Network -> Wireless -> [Edit] on 2,4 GHz or 5GHz interface
Interface Configuration -> Wireless security

Option is only:

WPA2-PSK (strong security)
WPA2-EAP (strong security)
WPA3-SAE (strong security)
WPA2-PSK/WPA3-SAE Mixed Mode (strong security)
WPA-PSK/WPA2-PSK Mixed Mode (medium security)
WPA-PSK (medium security)
WPA-EAP (medium security)
WEP Open System (weak security)
WEP Shared Key (weak security)
OWE (open network)
No Encryption (open network)

... and unfortunately no

WPA3-EAP / WPA2-EAP Mixed Mode
WPA3-EAP

there.
I also tried wpad-wolfssl, but the same issue.
See also https://forum.openwrt.org/t/wpa3-support-in-openwrt/10554/109

I have the same problem with the 19.07.0 release version and haven't found a solution so far.

Not that it is a very good choice but "WPA-EAP/WPA2-EAP Mixed Mode (medium security)" is not listed either. Maybe related why mixed modes do not support EAP?

I just tried something, it just seems like a config GUI problem. when I manually set option encryption 'wpa3-mixed' LuCI will correctly display mixed WPA2/WPA3 802.1X (CCMP) in the overview, but when changing settings it will display random settings and mode is set to WPA2-PSK and no EAP settings at all.

Issue still exists in 19.07.2.

Issue still exists in OpenWrt 19.07.2 r10947-65030d81f3


How to set prefetch_factor?

Hi, I am trying to train on custom data (which is in coco instance seg format). I have followed your suggestions for registering the data and using instance_coco_custom_dataset_mapper.py for it. Dataloading with data distribution visualization part is done successfully, however, I get error in line 339, in build_batch_data_loader:
data_loader = torchdata.DataLoader(
File "/home/pari/anaconda3/envs/oneformer/lib/python3.8/site-packages/torch/utils/data/dataloader.py", line 183, in init
assert prefetch_factor > 0
TypeError: '>' not supported between instances of 'NoneType' and 'int'
For me, prefetch_factor is None and I see no way of setting it in config so far. Can you help me figure out how to set it up - config file for custom instance segmentation would be a great help as well!
(I tried both single GPU for debugging and multiGPU but get same error) @praeclarumjj3
Thanks in advance!

So I manually set the default as 1 and it works so far, but would love to know what's the solution.
Another warning I am getting while training is:
WARNING [10/02 23:53:15 d2.checkpoint.c2_model_loading]: norm.weight will not be loaded. Please double check and see if this is desired.
WARNING [10/02 23:53:15 d2.checkpoint.c2_model_loading]: Shape of norm.bias in checkpoint is torch.Size([1536]), while shape of sem_seg_head.predictor.transformer_cross_attention_layers.6.norm.bias in model is torch.Size([256]).
Any suggestions/comments? @praeclarumjj3


Choosing more than 1 monster trait leads to crash.

Do you mean in the editor or when running the quest?  The D2E example quest does this.  Please provide a log and if in the quest a save game before the crash.

When I use e.g. the water and dark trait, both, Start Quest and Quest Editor lead to crash as soon as the quest is selected. This occurs only if no monster type is chosen. If one trait is chosen all is fine. Which log file would you like to have?

I still can't reproduce this.  Please provide either the quest or a save immediately before the crash.

Looked into that again and narrowed the problem down to the trait "civilized". There is a typo in Valkyrie here: "civilised". This might cause the crash.

  I have changed them, it is likely that your selection couldn't match anything.
It is very helpful to look in the log here: valkyrie_Data/output_log.txt.  Also to attach this to issue reports.

In the multilanguage translation process I will convert all traits into keys. So this won't be a problem.
We could introduce 2 different languages: American and English ;P


Cast error on GetAzureSubscriptionUtilization.java. Latest version

Steps to reproduce
Running https://github.com/microsoft/Partner-Center-Java-Samples/blob/master/sdk/src/main/java/com/microsoft/store/partnercenter/samples/utilization/GetAzureSubscriptionUtilization.java
Actual behavior
ClassCastException occured : okhttp3.Response cannot be cast to com.microsoft.store.partnercenter.models.ResourceCollection
Running partnercenter-1.12.0.

@renutz would it be possible for you to share a Fiddler trace for this? It will help me debug this issue a little more quickly.
Isaiah Williams

From: renutz<EMAIL_ADDRESS>Sent: Thursday, May 9, 2019 7:50:52 PM
To: microsoft/Partner-Center-Java-Samples
Cc: Subscribed
Subject: [microsoft/Partner-Center-Java-Samples] Cast error on GetAzureSubscriptionUtilization.java. Latest version (#10)
Steps to reproduce
Running https://github.com/microsoft/Partner-Center-Java-Samples/blob/master/sdk/src/main/java/com/microsoft/store/partnercenter/samples/utilization/GetAzureSubscriptionUtilization.javahttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FPartner-Center-Java-Samples%2Fblob%2Fmaster%2Fsdk%2Fsrc%2Fmain%2Fjava%2Fcom%2Fmicrosoft%2Fstore%2Fpartnercenter%2Fsamples%2Futilization%2FGetAzureSubscriptionUtilization.java&data=02|01||8e373b6fb20340538a8408d6d4e18d65|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636930462530414078&sdata=ojas7TJm%2FSm%2Bol6MPZHAarSJz%2F1sr1F5wCmDdpYTJvM%3D&reserved=0
Actual behavior
ClassCastException occured : okhttp3.Response cannot be cast to com.microsoft.store.partnercenter.models.ResourceCollection
Running partnercenter-1.12.0.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FPartner-Center-Java-Samples%2Fissues%2F10&data=02|01||8e373b6fb20340538a8408d6d4e18d65|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636930462530424083&sdata=8RvKU4GTb2bDVIxVVr0WH7y2h1TFGoWo4B25mc1U768%3D&reserved=0, or mute the threadhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFBHBXO6S2IOBROYAHNA7STPUTBGZANCNFSM4HL7ALKA&data=02|01||8e373b6fb20340538a8408d6d4e18d65|84df9e7fe9f640afb435aaaaaaaaaaaa|1|0|636930462530434088&sdata=SM9r8HPy4BBfE4zOS9XGrq1yV6WbbG7ktfqEdqnELjw%3D&reserved=0.

Hi Isaiah. Thanks for the promptness.
There is no change at all from the samples. Compiling and having an CSP Appid, appkey should be enough to find the error.

@renutz with my test environment the request is executing as expected. It would be helpful to see a trace of the request that is failing. Specifically I curious if the request for Azure Utilization records is returning a response with a HTTP status code of 204. If you could let me know the status code of your response it should help narrow down what is happening.

Understood. I'll see what I can do from here. Thanks

We just realized we were using an old version client-runtime (1.6.2 instead of 1.6.5). After the upgrade it worked.
Sorry to bother you and thanks for the attention!

This azure internal class cast exception is still happening with the version:
		<dependency>
		    <groupId>com.microsoft.azure</groupId>
		    <artifactId>azure</artifactId>
		    <version>1.35.1</version>
		</dependency>

java.lang.ClassCastException: class okhttp3.Response cannot be cast to class com.microsoft.store.partnercenter.models.ResourceCollection
I've observed the exception when calling the query() method with these conditions:
	new DateTime().minusDays(2),  //startTime
	new DateTime(), 			  // endTime  (notice empty constructor(current date time))
	AzureUtilizationGranularity.HOURLY

I also observed the exception with these conditions:
	new DateTime().minusHours(2),  //startTime
	new DateTime().minusHours(1),  // endTime
	AzureUtilizationGranularity.HOURLY

When I use these slightly different options, the exception does not happen and I receive query results:
	new DateTime().minusDays(2),  //startTime
	new DateTime().minusDays(1),  // endTime  (notice 1 day in the past instead of current DateTime)
	AzureUtilizationGranularity.HOURLY,

It looks like the issue is that the query method is either:

unable to handle the "current date time" as the endTime param with at least the HOURLY granularity
or
unable to handle returning an empty collection when no results are found for these conditions

Can the issue be reopened?


[New Feature]: Adding music to the game

🎮 feature Request
feature logic and basic description: adding music to the game
Point down the features
feature points:
-can hear to music while playing
Select program in which you are contributing
GSSoC24
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

@Durgesh4993 Please assign me the issue

Hi,
I can add some gaming music to the background please assign me this task

/assign

@Saipradyumnagoud shall I start working on it?

@Saipradyumnagoud shall I start working on it?

no I am not PA
by the way this issue was raised by me


SPL Token CLI Mint Creation Doesn't Allow Setting Freeze Authority

Overview
When creating a token mint from the CLI, there is no ability to set the freeze authority. This means that token mints created through the CLI as of version 2.0.15 will be forever unable to have their freeze authority set due to this line of the set authority code, which prevents that from happening:
                    // Once a mint's freeze authority is disabled, it cannot be re-enabled by
                    // setting a new freeze_authority
                    let freeze_authority = mint
                        .freeze_authority
                        .ok_or(Into::<ProgramError>::into(TokenError::MintCannotFreeze))?;
                    Self::validate_owner(
                        program_id,
                        &freeze_authority,
                        authority_info,
                        account_info_iter.as_slice(),
                    )?;
                    mint.freeze_authority = new_authority;

I think this is what you're looking for (since v2.0.2):
$ spl-token create-token -h
spl-token-create-token
Create a new token

USAGE:
    spl-token create-token [FLAGS] [OPTIONS] [--] [TOKEN_KEYPAIR]

FLAGS:
        --enable-freeze               Enable the mint authority to freeze associated token accounts.
        ...

There currently isn't a way to customize the freeze authority via the cli, but you can certainly set it.


Additional Hash Functionality

Currently Qo can only go one level deep on hashes with matchers. Everything else would be compared normally.
Consider adding deep hash querying or methods to help with it like a dig wrapper of some sorts:
# source data: https://jsonplaceholder.typicode.com/users
Qo[
  Qo.dig('address.zipcode', /92998/)
] == users.first

# Raw implementation - have to account for symbol or string keys
def dig(path_string, matcher)
  path_segments = path_string.split('.')
  path_sym_segments = path_segments.map(&:to_sym)

  -> target {
    matcher === target.dig(*path_segments) ||
    matcher === target.dig(*path_sym_segments)
  }
end

This would implement the same API as dig with a proc. As dig returns nil for a non-match we can just check the final === match regardless. I do wonder what it'd do with indexes like dig supports though. Not sure if that works with strings.
This does raise the question though of whether or not a similar behavior should be present on objects. It could be emulated using reduce:
value = dig_path.split('.').reduce(target) { |v, s|
  break nil unless v.respond_to?(s)
  v.public_send(s)
}

matcher === value

Anyways, there are some questions I should answer before writing this one.

Branch out - https://github.com/baweaver/qo/tree/deep-match-hash-and-dig
Example:
Qo.and(a: {
  f: 5..15,
  b: {
    c: /foo/, d: 10..30
  }
}).call({a: {
  f: 10,
  b: {
    c: 'foobar',
    d: 20
  }
}})

# match_key:    a
# match_value:  {:f=>5..15, :b=>{:c=>/foo/, :d=>10..30}}
# match_target: {:a=>{:f=>10, :b=>{:c=>"foobar", :d=>20}}}
#   match_key:    f
#   match_value:  5..15
#   match_target: {:f=>10, :b=>{:c=>"foobar", :d=>20}}
#   match_key:    b
#   match_value:  {:c=>/foo/, :d=>10..30}
#   match_target: {:f=>10, :b=>{:c=>"foobar", :d=>20}}
#     match_key:    c
#     match_value:  (?-mix:foo)
#     match_target: {:c=>"foobar", :d=>20}
#     match_key:    d
#     match_value:  10..30
#     match_target: {:c=>"foobar", :d=>20}
# => true

Qo.and(Qo.dig('a.b.c', /foo/)).call({
  a: {b: {c: 'foobar'}}
})
# => true

Ignore the debugger output, it was mostly for sanity checking. Strangely it worked on the first time though, so I'm particularly worried about it 😆

Resolved by: https://github.com/baweaver/qo/commit/1baed1f352889a89440a151494eede4529be2dea


deploy OpenShift registry-console with openshift-ansible

Signed-off-by: Adam Miller<EMAIL_ADDRESS>
What this PR does / why we need it:
Deploy's OpenShift registry-console with openshift-ansible for OpenShift Container Platform and OpenShift Origin Deployments.

@maxamillion please rebase on latest master, one of the tests should fail now and require you to check in generated code.

@kargakis why are we checking in generated code?

@jim-minter and @jackfrancis should know better but from what I remember we
had issues with static validation.
On Apr 30, 2018 16:12, "Adam Miller"<EMAIL_ADDRESS>wrote:

@kargakis https://github.com/kargakis why are we checking in generated
code?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Azure/acs-engine/pull/2792#issuecomment-385409884,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADuFf4340E_zoAxEbLE1tEpK2Zodzj97ks5ttxu6gaJpZM4TqfaC
.

@maxamillion checking in validated code unblocked our compilation CI. From a high level I think this can be classified as a // TODO in terms of how to make go-bindata + CI maintainable long-term. Open to any practical ideas. (but let's not functionally block this PR, I reckon)

lgtm, please merge


Simd sgradient

It seems that gcc can not optimise this so applying simd here give us a good performance gain.

It's mixing more than one pull request so closing it and opening a fixed one later.


Cloud Native Chapter 10

Summary
Cloud Native Chapter 10 files

Sounds good. We're going to have product teams reviewing the draft, too, but I can't produce the draft document until all 10 chapters are in one branch in your repo. Merge when ready.

@mairaw merge?


No LiveReload on completely fresh CRNA + storybook.

Hey there, I've followed a guide to set up a brand new CRNA and storybook environment.
After running getstorybook in a fresh CRNA, and changing the App.js to
export default from './storybook'
I can see that my app is running, and i can view the emoji / "Hello Button" buttons, and see the actions and all, but if I change the button text to "Hello Buttonnnnnnnn" I'll see the "Hot loading..." notification on my phone, but it won't actually update until I toggle from one story, and then back to the story I'm on. (Meaning it's half working, but I don't see changes until rerendering)
Current package.json
  "devDependencies": {
    "react-native-scripts": "1.3.1",
    "jest-expo": "~20.0.0",
    "react-test-renderer": "16.0.0-alpha.12",
    "@storybook/react-native": "^3.2.8",
    "@storybook/addon-actions": "^3.2.6",
    "@storybook/addon-links": "^3.2.6",
    "react-dom": "16.0.0-alpha.12",
    "prop-types": "^15.5.10"
  },
  "main": "./node_modules/react-native-scripts/build/bin/crna-entry.js",
  "scripts": {
    "start": "react-native-scripts start",
    "eject": "react-native-scripts eject",
    "android": "react-native-scripts android",
    "ios": "react-native-scripts ios",
    "test": "node node_modules/jest/bin/jest.js --watch",
    "storybook": "storybook start -p 7007"
  },
  "jest": {
    "preset": "jest-expo"
  },
  "dependencies": {
    "babel-preset-es2015": "^6.24.1",
    "babel-preset-stage-2": "^6.24.1",
    "expo": "^20.0.0",
    "react": "16.0.0-alpha.12",
    "react-native": "^0.47.0"
  }

The livereloading was working on the CRNA app itself.

I think I've came across this at one point as well. Can anyone else reproduce this on the latest or 3.3-alpha?

fixed https://github.com/storybooks/storybook/pull/2194
for existing projects, you'll need to replace the root storybook app with a react-native class component instead of a functional stateless component
https://github.com/storybooks/storybook/issues/2081


View with stored data

I think it was better to have a view that stores its query result to access quickly.

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

ID: e7bfcbf2-4dbb-6a41-4390-40d6bc076606
Version Independent ID: 2992dd77-8134-c2ea-8957-3a696583a2c4
Content: Views - SQL Server
Content Source: docs/relational-databases/views/views.md
Product: sql
Technology: table-view-index
GitHub Login: @stevestein
Microsoft Alias: sstein

@ma17961363 -- thank you for your feedback.  Can you please give us more information about your task or issue?

I am closing this issue now.  You are welcome to @ mention me for any followup.
We hope to hear from you again.


BMP file extension is not sustained

BMP
File binary is PNG
When we compress a bmp image, the binary of the file is changed to PNG
Even though the file type is image/bmp and the name xxxxxx.bmp

v2.0.1 now supports bmp.


refactored logging into LogUtil, this is a more robust solution than …

…previously, where you might forget the if statement. Use the log util now. closes #46

I deliberately omitted javadoc per method, to instead keep it all in the description of the class.
This way I avoid repeating myself (thus avoiding duplicate and useless extra lines).
I feel like
/**
 * This class serves as a wrapper around the android.util.Log class.
 * It makes sure logs are only generated in the debug build variant.
 *
 * Putting the checks in this class instead of before every log individually reduces human-errors
 * (i.e. you might forget to add a check somewhere).
 *
 * This way, we can use the Android Studio search tool to make sure there is only one 'Log.e(...)'
 * statement in the entire project.
 *
 * Suggestion: It would be better to use ProGuard to remove logs in the release build variant.
 * This, however, has proven to require a lot of understanding about ProGuard and thus time consuming.
 */

Is descriptive enough for the entire class.
However, I added a suppress warnings for javadocs on methods to explain this in the code as well.

Fair enough since it's internal code. Approving this PR.


policies should be list not map

TOSCA 1.3 section <IP_ADDRESS>.1 defines polices within a topology template as a list of policy definitions but in v0.12.0 examples/Tosca/policies-and-groups.yaml has the backup policy defined as a map. If I change it to a list like this:
policies:
- backup:
    type: ContinuousBackup
    properties:
      frequency: .5 d
    targets:
    # Target node templates and groups must match our definition at the policy type
    # (Can include derived types)
      - server2
      - redundants

the validation fails with in the error:
@106,3 topology_template.policies: "!!seq" instead of "!!map"

First of all, you are right and this will be fixed.
Second ... this is a surprisingly complex little issue! I raised it in the TOSCA ad-hoc meeting today and nobody could explain why it is a sequenced list, when groups, etc., are maps. It may have been an error, which is indeed how I interpreted it originally. (There are many errors in the spec.)
As a list, does it mean that two policies can have the same name? Or does the list just mean a (potential) order of priority in which they are implied? For Puccini, I will decide on the latter. I can't tell you what other parsers will do, because the spec is open to interpretation.
As for the history of this confusion, check out this section in 1.2. You see that all keywords are specified as "list of ...". That is obviously an error, and indeed existed since 1.0. So, many of us assumed that it really means map.
But ... this same section was fixed in 1.3... except that only policies were left as a list, and indeed in the section you mention it has stayed a list.
Maybe this was an oversight? I think it probably was, because nobody can provide a reason. :)
In any case, for better or for worst I agree.


docs: fix typo

Hey @revolunet , thanks for the contribution. I will merge the request into master.


immich-cli: 0.41.0 -> 2.0.6

Description of changes
Updates immich-cli to version 2.0.6
The immich cli version is different from immich repo, so version is imported from package.json.
closes #274787

Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] 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/)
24.05 Release Notes (or backporting 23.05 and 23.11 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

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

@ofborg eval

Thanks for the review! Updated the code.

Please ask upstream to separately tag CLI releases if they don't share a version number.

I was not falimiar with the import from derivation case. (I kind of asumed that if it compiles, it is okay.)
Iwill see if I could ask for the cli version numbers, but for now, is it best to just hard code the version numbers?

for now, is it best to just hard code the version numbers?

Yes, but revshould point to the actual commit at which the version was published on NPM rather than the most recent immich version.

@dotlambda Thanks again for the review!
I got the exact commit that is used when it was uploaded to npm, so this should be the same as using the version on npm.


linux + vscode + azure extensions aren't the best experience.

<Please be sure to remove any private information before submitting.>
Repro steps:
<Enter steps to reproduce issue>
Action: appService.CreateWebApp
Error type: Error
Error Message:

Microsoft Azure Web App - Error 404

Hi @Peterson-peter,
Thanks for reporting this issue.  We're sorry that the Linux experience is a bit lacking right now.  As far as this error is concerned:

Were you trying to just create a web app through the extension? If so, is this a Linux or Windows web app?
Are you trying to view a web app that has a custom domain?

Thanks for your help in resolving this issue!

I'm attempting to create a bot in azure. I've added the Azure extension into VScode linux. Deployment from this method is a little buggy. The first and oddest bug is that the confirmation dialog box can't be clicked with a mouse, but you can use keyboard to select the correct key. Deployments don't appear to go well using a python 3.7 deployment template, but it was shakey enough that I just gave up and deployed a VM and went old school. Sorry I can't recall the entire experience at this point.

Closing due to lack of repro steps. If you run into this error again let us know


issue in creating new project

@Nagendragose  If this is the beginning of any issue, please provide more information.
Thanks!


Update dependencies and translations to the most recent versions

/botio-linux preview

/botio test

@calixteman Hm, it looks like the Linux bot does receive commands, but the logs are not visible. Could you check why that is?

Well, tar errors that keep the bot busy for 2 hours is a first... Let's try that again:
/botio-linux test


modules/rpm: workaround when ext_prog not found locally

Traceback (most recent call last):
  File "../../../meson.py", line 184, in <module>
    app.generate()
  File "../../../meson.py", line 130, in generate
    intr.run()
  File "/home/brain/git/upstream/meson/interpreter.py", line 828, in run
    self.evaluate_codeblock(self.ast)
  File "/home/brain/git/upstream/meson/interpreter.py", line 850, in
evaluate_codeblock
    raise e
  File "/home/brain/git/upstream/meson/interpreter.py", line 844, in
evaluate_codeblock
    self.evaluate_statement(cur)
  File "/home/brain/git/upstream/meson/interpreter.py", line 897, in
evaluate_statement
    return self.method_call(cur)
  File "/home/brain/git/upstream/meson/interpreter.py", line 1620, in
method_call
    return obj.method_call(method_name, args, kwargs)
  File "/home/brain/git/upstream/meson/interpreter.py", line 625, in
method_call
    value = fn(state, args, kwargs)
  File "/home/brain/git/upstream/meson/modules/rpm.py", line 98, in
generate_spec_template
    fn.write('BuildRequires: %s\n' % ' '.join(prog.fullpath))
TypeError: sequence item 0: expected str instance, NoneType found

Instead of /usr/bin/%s # FIXME\n' % prog.get_name() maybe we should use prog.get_command()[0]. It is an absolute path if the binary is from the system and not a script inside the source tree.

@jpakkane but get_command() returns [None] if program not found and we can't add None to BuildRequires, so trying to guess it is from /usr/bin with #FIXME.

Crap, I read that wrong. Sorry about that. Merging.


Axis ticks label positions is not scaled well

Problem
I feel like the X/ Y Axis label positions are not scaled/ aligned well. So I'm using this chart example (Chart-2) with my data:
https://github.com/tui-rs-revival/ratatui/blob/v0.22.0/examples/chart.rs
let data: Vec<(f64, f64)> = vec![
    (0.0, 19799459.0),
    (1.0, 21077099.0),
    (2.0, 20541902.0),
    (3.0, 18909404.0),
    (4.0, 18645169.0),
    (5.0, 21282285.0),
    (6.0, 22234309.0),
    (7.0, 20949579.0),
    (8.0, 20605463.0),
    (9.0, 16719816.0),
    (10.0, 18607126.0),
    (11.0, 18926021.0),
    (12.0, 19928185.0),
    (13.0, 19101790.0),
    (14.0, 20660632.0),
    (15.0, 21492383.0),
    (16.0, 21660903.0),
    (17.0, 16454098.0),
    (18.0, 17100739.0),
    (19.0, 17338056.0),
    (20.0, 17587407.0),
    (21.0, 18099830.0),
    (22.0, 18694563.0),
    (23.0, 19575447.0),
    (24.0, 19339535.0),
    (25.0, 20159173.0),
    (26.0, 22084681.0),
    (27.0, 25031109.0),
    (28.0, 27390012.0),
    (29.0, 30009448.0),
    (30.0, 32878528.0),
    (31.0, 34278063.0),
    (32.0, 34248061.0),
    (33.0, 35727267.0),
    (34.0, 33514861.0),
    (35.0, 31185488.0),
    (36.0, 30585935.0),
    (37.0, 32593481.0),
    (38.0, 33444410.0),
    (39.0, 32279025.0),
    (40.0, 32610465.0),
    (41.0, 35403858.0),
    (42.0, 36644960.0),
    (43.0, 34029229.0),
    (44.0, 30687033.0),
    (45.0, 32105288.0),
    (46.0, 33825097.0),
    (47.0, 34940276.0),
    (48.0, 35969156.0),
    (49.0, 39090908.0),
    (50.0, 39496700.0),
    (51.0, 41588700.0),
    (52.0, 42880681.0),
    (53.0, 41811780.0),
    (54.0, 40707691.0),
    (55.0, 40931338.0),
    (56.0, 41699624.0),
    (57.0, 45766022.0),
    (58.0, 44967751.0),
    (59.0, 44355027.0),
    (60.0, 12024798.0),
    (61.0, 40901754.0),
    (62.0, 39843440.0),
    (63.0, 38904796.0),
    (64.0, 37806717.0),
    (65.0, 38461775.0),
    (66.0, 43186864.0),
    (67.0, 42039035.0),
    (68.0, 38207590.0),
    (69.0, 40433229.0),
    (70.0, 38729080.0),
    (71.0, 40141267.0),
    (72.0, 38300050.0),
    (73.0, 28676588.0),
];

let datasets = vec![Dataset::default()
    .name("data")
    .marker(symbols::Marker::Braille)
    .style(Style::default().fg(Color::Yellow))
    .graph_type(GraphType::Line)
    .data(&data)];
let chart = Chart::new(datasets)
    .block(
        Block::default()
            .title("Chart 2".cyan().bold())
            .borders(Borders::ALL),
    )
    .x_axis(
        Axis::default().title("X Axis").bounds([0.0, 73.0]).labels(
            ["0.0", "20.0", "40.0", "60.0", "73.0"]
                .iter()
                .cloned()
                .map(Span::from)
                .collect(),
        ),
    )
    .y_axis(
        Axis::default()
            .title("Y Axis")
            .style(Style::default().fg(Color::Gray))
            .bounds([0.0, 46000000.0])
            .labels(
                [
                    "0.0",
                    "10000000.0",
                    "20000000.0",
                    "30000000.0",
                    "40000000.0",
                    "46000000.0",
                ]
                .iter()
                .cloned()
                .map(Span::from)
                .collect(),
            ),
    );
f.render_widget(chart, chunks[1]);

And here is what looks like in the terminal

So is there any incorrect setup with my data? Even if I divide 73.0 by 5 (number of labels) and set it, it still looks too wide/ narrow between ticks.
Additional context
ratatui = { version = "0.22.0" }

The reason for this odd display is that the left and right ticks are written at the start / end of the section, while the other ticks are written centered. (I don't know the logic behind the decision - you'd have to look back into the tui-rs history to work that out). I'd imagine this looks better with more ticks, but it's still odd.
Added yellow ticks to show where the logic thinks the ticks are:

Relevant code:
https://github.com/tui-rs-revival/ratatui/blob/13fb11a62c826da412045d498a03673d130ec057/src/widgets/chart.rs#L411-L425

Digging a little deeper this was implemented in https://github.com/fdehau/tui-rs/pull/568
Prior to that the labels were off center. It seems like what happened is that the tests looked at this being fixed for the case of 3 labels, and didn't notice the issue that the mat was still wrong for calculating the x-axis label positions.
For 3 labels, the logic chops the axis in 3 and then renders the middle label in the middle of the middle section. This has the effect of correctly rendering the position as  the center of [1/3..2/3] is 1/2.
Move to four labels however and labels 2 and 3 are incorrectly placed, as the center of [1/4..2/4] and [2/4..3/4] are not 1/3 and 2/3, but instead 3/8 and 5/8.
To fix this, we need to reduce the number of areas allocated by 1 and set the start / end of each label to half back from  the current tick to halfway past the current tick and then center that.
It might also be nice to add a actual tick by using the unicode cross: '┼ ' at the points.

@joshka I'd like to pick up this issue if possible.
However I have a question regarding the labels, does it make sense to allow labels that are not multiples of the first label (73 in this case)? Or is this out of scope? I feel like labels could be, by default, automatically deduced

Go for it. You asked a couple of questions in the pre-edited message. My answer is that I'm not sure. I suspect there are two parts to this - positioning correctly and working out the right points to make.
The primary approach I use to understand whether to make a change like you suggested is to try to work out the impact on existing applications. Is it simple for an app developer to fix any backwards incompatible change? Can we notify them with an added field and deprecating any old field before changing it in a future version? Is there behavior that if changed would break apps? Is there a way of doing the change that maintains backwards compatibility?
A good github search to find usages of <some term> is lang: rust ratatui <some term> AND (NOT org:ratatui-org) AND (NOT is:fork)

To anyone wanting to patch this from userland, here is an example of function you can use by fiddling with the buffer itself:
fn lerp(min: f64, max: f64, t: f64) -> f64 {
    (1.0 - t) * min + t * max
}

fn patch_buffer(buffer: &mut Buffer, area: Option<&Rect>, x_ticks: &Vec<String>) {
    let area = *area.unwrap_or(buffer.area());

    let origin_col = (area.x..area.x + area.width)
        .find(|x| buffer.cell((*x, area.y)).unwrap().symbol() == "│")
        .unwrap();

    // Drawing ticks for y axis
    for y in area.y..area.y + area.height {
        let cell = buffer.cell((origin_col, y)).unwrap();

        if cell.symbol() == "│"
            && (area.x..origin_col).any(|x| buffer.cell((x, y)).unwrap().symbol() != " ")
        {
            buffer.cell_mut((origin_col, y)).unwrap().set_symbol("┼");
        }
    }

    // Fixing ticks for x axis
    let x_axis_line_y = area.y + area.height - 2;
    let x_axis_legend_y = x_axis_line_y + 1;
    let x_axis_end_pos = (area.x + area.width - 1, x_axis_line_y);

    for x in area.x..area.x + area.width {
        buffer.cell_mut((x, x_axis_legend_y)).unwrap().reset();
    }

    let steps = x_ticks.len();
    let mut t = 0.0;
    let fract = 1.0 / (steps - 1) as f64;

    let first_tick = x_ticks.first().unwrap();
    buffer.set_string(
        origin_col
            .saturating_sub(first_tick.width() as u16)
            .min(area.x),
        x_axis_legend_y,
        first_tick,
        Style::new(),
    );

    for i in 1..(steps - 1) {
        t += fract;
        let x = lerp(origin_col as f64, (area.x + area.width - 1) as f64, t) as u16;
        buffer.cell_mut((x, x_axis_line_y)).unwrap().set_symbol("┼");

        let tick = &x_ticks[i];
        buffer.set_string(
            x - (tick.width() / 2) as u16,
            x_axis_legend_y,
            tick,
            Style::new(),
        );
    }

    let last_tick = x_ticks.last().unwrap();

    buffer.set_string(
        area.x + area.width - last_tick.width() as u16,
        x_axis_legend_y,
        last_tick,
        Style::new(),
    );
    buffer.cell_mut(x_axis_end_pos).unwrap().set_symbol("┼");
}

@Yomguithereal Drawing a grid would be a great addition to the widget I think... Would you consider working on a PR to fix this issue and another to add that functionality?

Will definitely try to do so if I can find the time :)


Log in issue

Description
Hello,
I have a connection problem with Jellyfin. When I try to log in, every user, including the admin, gives me an error message. I tried creating a new user on Jellyfin with the username “test” and the password “test,” but those credentials don’t work either. Can you help me with this issue?
This issue is new; I could connect before, and now it's impossible, even though I haven't changed anything in my configuration.
Version
I can’t see cuz I can’t log
Steps to Reproduce

Create a new profile in Jellyfin
Log in with this profile in jellyseerr
Error message : Something went wrong while trying to sign in.

Screenshots
Logs
No response
Platform
desktop
Device
Asus rog
Operating System
Windows
Browser
Edge
Additional Context
No response
Code of Conduct

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

Hello, same issue, i can't log in my Jellyseerr account i have a 401 error (Unauthorized) and my friends have same problem too...

@leomrch just to confirm, is your issue solved?
@Bondou what about you?
(cant remember if you hopped onto discord or not since this issue wasnt updated afterwards)

Hello, sorry for the late response but i solved the problem by uninstalling and install Jellyseerr again

same issue

same issue

Hop onto discord. With more information


Support jacoco and Codecov

What's changed?

Checklist

[ ]  I have read the Contributing Guide
[ ]  I have written the necessary doc or comment.
[ ]  I have added the necessary unit tests and all cases have passed.

Add or update API

[ ] I have added the necessary e2e tests and all cases have passed.

Welcome to Codecov :tada:
Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.
Thanks for integrating Codecov - We've got you covered :open_umbrella:


Add simple whole image reader and writer

It is easier to just read or write using whole buffer instead of row by row API. On reading it should also automatically convert from paletted to RGB if requested.

i will create a PR for this


Update go-libp2p-daemon build version.

Fix build errors by updating the used version to a working one. Also, it's the one used in the CI for testing.

@AlejandroCabeza could please explain what build errors this is fixing?
@kaiserd If I remember correctly, I tried to use a newer version and it didn't work. It's not clear to me why this daemon is even necessary. I'd suggest removing it altogether.

Thank you! Is there a reason why we do not used the tagged versions? v0.35.0 is only 14 days old. Seems to be recent enough. We could update the CI to that, too.

@kaiserd I'm fine having a look to see whether we can update the daemon to a more recent version. In any case I'd merge this PR regardless, and take that as a follow-up task.

could please explain what build errors this is fixing?

@diegomrsantos Just build errors, I'm not a go expert so I can't elaborate. But it's as simple as running the build script as it is, you'll get those errors.

It's not clear to me why this daemon is even necessary. I'd suggest removing it altogether.

@diegomrsantos The p2pd binary is used for running tests. I'm positive that's mentioned in the README.

@AlejandroCabeza I meant when those build errors occur. As I've done this a long time ago, I don't remember. Using the current script to install it locally doesn't work?
I meant it's not clear to me why we need p2pd to run tests as the vast majority of them don't need it. I think it's required only for 4 or so. I suggest investigating it and either removing all those tests or removing the dependency on the daemon.

I meant when those build errors occur. As I've done this a long time ago, I don't remember. Using the current script to install it locally doesn't work?
@diegomrsantos Correct, running it fails due to some xerrors library (or something like that).

I meant it's not clear to me why we need p2pd to run tests as the vast majority of them don't need it. I think it's required only for 4 or so. I suggest investigating it and either removing all those tests or removing the dependency on the
@diegomrsantos No clue, but I think that's a different job altogether. If you think it's worth considering, would you mind writing an issue for it so we can discuss it during next weekly?

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 84.50%. Comparing base (02c96fc) to head (ec3c710).
Report is 14 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1111      +/-   ##
==========================================
- Coverage   84.53%   84.50%   -0.04%
==========================================
  Files          91       91
  Lines       15517    15531      +14
==========================================
+ Hits        13118    13124       +6
- Misses       2399     2407       +8

see 18 files with indirect coverage changes


There is a vulnerability in axios:0.21.4,upgrade recommended

https://github.com/microsoft/nni/blob/2e3a777062fa2f1c224c9e954374e699e6d66838/ts/webui/yarn.lock#L3184-L3185
CVE-2022-1214
Recommended upgrade version：0.26.0

@QiAnXinCodeSafe Could you close this issue? had a fix PR.

done.


Update hass support version range in README

Seems hass support version range in README is outdated.

Not yet. Lights has a problem :)

OK then, closed.


Timestamp authority response verification during signing

Description

We should verify the response from the timestamp authority when it's received, as per RFC 3161:
Upon receiving the response (which is or includes a TimeStampResp
   that normally contains a TimeStampToken (TST), as defined below), the
   requesting entity SHALL verify the status error returned in the
   response and if no error is present it SHALL verify the various
   fields contained in the TimeStampToken and the validity of the
   digital signature of the TimeStampToken.

We'll need to add the timestamp-cert-chain flag for signing.

+1 overall
-1 to the name timestamp-cert-chain for the reasons I describe in https://github.com/sigstore/cosign/issues/2472

We can refactor that. This flag will also be unnecessary if you ship the TSA trust roots with TUF.

@haydentherapper and I discussed this; we decided go with --timestamp-cert-chain for now, then rename both this and --cert-chain as part of #2472.

@znewman01 I remember we initially used --timestamp-cert-chain but we recently renamed to --timestamp-certificate-chain. Do we still want to change it ?

I’m working on this now. Yea, I will use certificate-chain

Removing myself from this if anyone else wants to take it on


Quaternion .fromUnitVectors addition

So there is a useful code that can find the quaternion required to move from 1 normalized unit vector to another. I wrote it from this: link
function fromUnitVectors (a,b) {
  var x = a[0]
  var y = a[1]
  var z = a[2]
  var vx = b[0]
  var vy = b[1]
  var vz = b[2]
  var c = [0,0,0]

  c[0] = y * vz - vy * z
  c[1] = z * vx - vz * x
  c[2] = x * vy - vx * y

  var d = a[0] * b[0] + a[1] * b[1] + a[2] * b[2];
  var q = [d,c[0],c[1],c[2]];
  var l = Math.sqrt(q[0]*q[0] + q[1]*q[1] + q[2]*q[2] + q[3]*q[3]);
  q[3] += l;

  return normalize(q)
}

Oh, is this what fromTo does.... the docs had it with 4 inputs
quat.fromTo(q, from, to, up)
I think ive reinvented the wheel here. Ill just just fromTo as I havnt tested this properly

The problem is there is no up vector in code. But yes it does the same thing.

One thing worth mentioning is that fromUnitVectors could be a sibling to fromPositionTarget which is a better name than lookAt.


A new "by-context" visualization to switch to when needed

I'd like to have the ability to switch the default view to a view that shows my tasks grouped by context and with the project name as a task detail'.
In this way, I could use the context to specify which is the GTD list the task belong (next actions, waiting for etc...) and toggle the visualization of my system between the default by-project view and the by-context view.
Thanks for you time and for this great plugin.

Sounds like a good idea. I've implemented it in v1.2.0.
The default grouping can be specified in the plugin's configuration and it can be changed on the todo page with a dropdown.
Thanks for the idea and the feedback.


Investigate contract interface type checking and/or manifest tooling

This description is updated with the resolution:
The design is here: https://github.com/stellar/rs-stellar-contract-sdk/issues/42#issuecomment-1143937788
The list of things to do now are here (https://github.com/stellar/rs-stellar-contract-sdk/issues/42#issuecomment-1146455941):

[x] stellar/rs-stellar-contract-sdk#114
[x] stellar/rs-stellar-contract-sdk#115
[x] stellar/rs-stellar-contract-sdk#116
[x] https://github.com/stellar/rs-stellar-contract-sdk/issues/24
[x] stellar/rs-stellar-contract-sdk#117
[ ] https://github.com/stellar/rs-stellar-contract-sdk/issues/153
[ ] https://github.com/stellar/rs-stellar-contract-sdk/issues/168
[ ] stellar/rs-stellar-contract-sdk#118
[x] stellar/stellar-contract-cli#6
[ ] stellar/stellar-contract-cli#7
[ ] stellar/stellar-contract-cli#8
[ ] https://github.com/stellar/rs-stellar-contract-sdk/issues/142

I looked through these links, and I think we can do the simplest thing for now, which given our alignment and use of Rust is probably a toml file that looks something like:
[contract]

[[fn]]
symbol = "add32"
args = ["i32", "i32"]
return_type = "i32"

[[fn]]
symbol = "add64"
args = ["i64", "i64"]
return_type = "i64"

[[fn]]
symbol = "hndmsg"
args = ["obj:binary"]
return_type = "bool"

The above example provides the fields as specified in CAP-47 (@sisuresh).
The example assumes that types can be referenced using the SCValType definition in CAP-47, here expressed in an abbreviated form but otherwise consistent.

A simple format like this will be relatively easy to convert into XDR when deploying, but nothing about it necessarily helps us validate a contract function, since a contract function implements itself its conversion logic and so that can only be tested by executing the function, but no general test can confirm that part of a contract is working correctly without potentially executing invalid values that cause the contract to fail for other reasons.

A large part of the problem of verifying code written by developers is that our contracts currently take the following shape. Since the inputs are all untyped RawVals there's not a lot we can do to validate the types that the functions will use internally.

Ideally we end up with code looking like this snippet, where function arguments are typed, it is easy to validate that a function matches a signature, and the conversion is largely hidden from the developer. We had a prototype of supporting this with a procedural macro in https://github.com/stellar/rs-stellar-contract-sdk/pull/9. However, this doesn't leverage the Rust compiler to actually do that verification, we'd probably have to use syn and some other crates to parse the signature and match it to the manifest.

To leverage the Rust compiler to validate the shape of the functions implemented we need to use traits to do something like the below. I think this gets us most things we want, except it isn't particularly portable to other languages. But it is compelling that a developer could share a trait and others could implement it, and everybody would be using the compiler they already have on their systems to guarantee compatibility. Of course, this would require us to use a procedural macro, like on the example above, to generate extern fns.

I think there's a plausible (and possibly kinda forced-on-us) point in the design space where "an interface" is defined as either an XDR manifest or a (bijectively mapped) Rust trait, and we have a proc macro on a unit type (or an impl?) that emits a bunch of global #[no_mangle] pub fns that receive RawVals and call through to to the associated methods on the unit type, with each arg run through into() or try_into(). I'd be willing to see how horrible that is. It's macros which I don't love, but I don't see a lot of other options at this point.

I agree, that's where I'm landing too. When I prototyped this previously in #9 the only benefit was to remove some boilerplate, but now the benefit is greater as it would include the trait being a way developers can share their contract interfaces.
I'm going to prototype this and then we can review it and see how bad the tradeoffs are.

You don't really need the impl there, afaict. You could just implement the contract as the default methods on the trait. e.g.
#[stellar::contract]
pub trait AddContract {
  fn add(_e: Env, a: i64, b: i64) -> i64 {
    a + b
  }
}

Would the typecasting wrapper @graydon suggested need to be a macro? Could it be a sort of runtime within wasm, that loads up the contract code, introspects it, and casts? Ah, no. because it would need the type signatures which are only available at compile time.

You don't really need the impl there, afaict.

To test the contract an impl will be required. Developer may as well write it that way. It also makes sharing the trait easier since you can copy and paste it anywhere without the impl. The moment the impl lives in the trait you can't do that.

@paulbellamy and I discussed this more today and I'm working towards something like the following diagram:

Rust trait is the source of the interface.
XDR is the common language all components speak.
CLI turns the XDR manifest into interfaces and code in client languages. (There may be other dapp tooling that also does this in other ways.)
A tool generates the XDR, either:

The macro I'm building in #109 will generate a custom wasm section that contains the XDR, such that the generation of the XDR occurs as part of compile time.
Some other tool, such as the CLI, will create the XDR from a Rust trait.

@paulbellamy and I also discussed who the stakeholders/users are, and the use cases, and came up with the following relationships and technologies that will possibly touch it:

Conversations with @paulbellamy and @jonjove have expanded this work in a few things, so I'm going to open issues for each of them and close this issue as I think we have a reasonably good high-level plan now:

[ ] Add impl attribute macro that writes out extern fns that wrap the impl fns, and unwrap/wrap RawVals.

[ ] Define XDR for manifest (take from CAP-47).

[ ] Experiment with custom sections and if we can store something like XDR in them. See if it is then also easy to extract that section, and strip that section, after compile.

[ ] Add a trait attribute macro that:

[ ] Add trait attribute macro that generates an XDR value that describes the functions of the trait, and inserts that XDR as a custom section in the final wasm.
[ ] Add trait attribute macro that generates a cross-contract calling impl.

[ ] Add CLI command that extracts XDR from .wasm.

[ ] Add CLI command that generates a Rust trait from .wasm.

All the plans live in subissues now, and I'm going to close this parent issue to continue to use the subissues. All issues relating to this will be prefixed with Contract Spec: .


DEPLOY-567: Update instructions for deploying the DBP on Windows

Sorry for doing this, but we are going to need this guide updated to the latest dns and value changes brought by BUILDER-96 in master.
I merged master here to get the latest updates. The changes are not pretty big but we do have some.

Using values files instead of helm install --set --set
Using nip.io and wildcard dns for local setup


Fix tooltip positioning on edit request page

/cc @tpetr

overall LGTM, but i noticed when the tootip appears, the button gets ~1px wider

^ Was due to a bootstrap bug with button groups. Made a workaround.

:dancer: thanks


GC_SAFETY_ASSERT FAILURE for manifold mesh

Hi @nmwsharp ,
first of all: Great library.
No to the actual problem: I am trying to use the EdgeFlipGeodesicSolver to find a path on a relatively simple mesh (vertices and faces below) and am receiving an GC_SAFETY_ASSERT FAILURE error like this:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\Users\my_user\AppData\Local\mambaforge\envs\stress\lib\site-packages\potpourri3d\mesh.py", line 64, in __init__
    self.bound_solver = pp3db.EdgeFlipGeodesicsManager(V, F)
RuntimeError: GC_SAFETY_ASSERT FAILURE from D:\a\potpourri3d\potpourri3d\deps\geometry-central\src\surface\manifold_surface_mesh.cpp:110 - duplicate edge in list 1 -- 2

Now, I saw in #18 that this is most likely due to a non-manifold edge. So I did some cleaning (I am using vedo for most mesh operations) with mesh.clean() and also sorted and searched all faces for duplicate triangles. When I check the mesh for whether it is a manifold-mesh using vedo like this, I get:
>>> mesh.is_manifold()
True

Here are the vertices and faces, if it helps to trace down the issue. Here is the mesh in question, in case it helps to debug the issue:
test.zip
Best & thanks for any help,
Johannes

Hi @jo-mueller,
I've had the same problem in the MeshVectorHeatSolver. I ended up manually reordering the mesh. It's just a quick a dirty solution, so not very efficient or anything, but maybe it helps you as well. reorder_edges_of_faces() does the trick for me:

Python code
from sys import setrecursionlimit
from typing import Annotated, Literal, TypeVar

import numpy as np
import numpy.typing as npt

DType = TypeVar("DType", bound=np.generic)
ArrayNx3 = Annotated[npt.NDArray[DType], Literal["N", "3"]]

def _get_duplicate_edges(F: ArrayNx3) -> list[list[int]]:
  """Get list of directed edges that belong to more than one face.

  Parameters
  ----------
  F : ArrayNx3
      Array of vertex indices that form the faces of the tessellation.

  Returns
  -------
  list
      List of duplicate edges.
  """
  edges = np.array([[[a, b], [b, c], [c, a]] for a, b, c in F]).reshape(
      F.shape[0] * 3, 2
  )
  e, c = np.unique(edges, axis=0, return_counts=True)
  return e[c > 1].tolist()

def _reorder_neighbours(
  F: ArrayNx3,
  current_face: int,
  faces_to_neighbours_map: dict,
  reordered_faces: list[int],
) -> ArrayNx3:
  """Recursively reorder neighbouring faces until there are no duplicate edges.

  Parameters
  ----------
  F : ArrayNx3
      Array of vertex indices that form the faces of the tessellation.
  current_face : int
      Index of the correctly ordered reference face whose neighbors are reordered.
  faces_to_neighbours_map : dict
      Dictonary mapping face indices to the indices of all not yet ordered neighbours.
  reordered_faces : list[int]
      List of faces that are already in correct order.

  Returns
  -------
  ArrayNx3
      Array of faces where the neighbours of `current_face` are ordered.
  """
  neighbours = faces_to_neighbours_map[current_face]
  for neighbour in neighbours:
      violation = _get_duplicate_edges(F[[current_face] + [neighbour]])
      if violation:
          F[neighbour] = [F[neighbour][2], F[neighbour][1], F[neighbour][0]]
      reordered_faces.append(neighbour)
      faces_to_neighbours_map[current_face].remove(neighbour)
      faces_to_neighbours_map[neighbour].remove(current_face)

  for i in reordered_faces:
      if faces_to_neighbours_map[i]:
          F = _reorder_neighbours(F, i, faces_to_neighbours_map, reordered_faces)
          break

  if not any(faces_to_neighbours_map.values()):
      return F
  else:
      raise RecursionError("Could not reach all vertices.")

def reorder_edges_of_faces(F: ArrayNx3) -> ArrayNx3:
  """Reorder edges of faces for `potpourri3d.MeshVectorHeatSolver`.

  Parameters
  ----------
  F : ArrayNx3
      Array of unordered faces

  Returns
  -------
  ArrayNx3
      Array of ordered faces
  """
  setrecursionlimit(5 * F.shape[0])

  empty_list: list[int] = []

  edges = np.array([[[a, b], [b, c], [c, a]] for a, b, c in F]).reshape(
      F.shape[0] * 3, 2
  )
  edges_to_faces_map = {(min(e), max(e)): empty_list.copy() for e in edges}
  for i, f in enumerate(F):
      edges_to_faces_map[(min(f[0], f[1]), max(f[0], f[1]))].append(i)
      edges_to_faces_map[(min(f[1], f[2]), max(f[1], f[2]))].append(i)
      edges_to_faces_map[(min(f[2], f[0]), max(f[2], f[0]))].append(i)

  faces_to_neighbours_map = {i: empty_list.copy() for i in range(F.shape[0])}
  for neighbours in edges_to_faces_map.values():
      if len(neighbours) > 1:
          faces_to_neighbours_map[neighbours[0]].append(neighbours[1])
          faces_to_neighbours_map[neighbours[1]].append(neighbours[0])
      if len(neighbours) > 2:
          faces_to_neighbours_map[neighbours[0]].append(neighbours[2])
          faces_to_neighbours_map[neighbours[2]].append(neighbours[0])
          faces_to_neighbours_map[neighbours[1]].append(neighbours[2])
          faces_to_neighbours_map[neighbours[2]].append(neighbours[1])
      if len(neighbours) > 3:
          raise ValueError("Something weird is happening.")

  return _reorder_neighbours(F, 0, faces_to_neighbours_map, [0])


📝 Documentation(i18n): Translate the Foundation page to French

Bug Report Checklist

[X] I have pulled the latest main branch of the repository.
[X] I have searched for related issues and found none that matched my issue.

Overview
Translate the Foundation Page to French; go to foundation.fr-FR.mdx and make the translations from there.

Additional Info

You can come into the docs channel in the Discord Server for further information. Do translate the front-matter as well.

Use an informal tone, not too informal though

Also, checkout the Contriibuting Guide incase you want to set up Million locally

Hi @tobySolutions, can you assign this issue to me ?
I've joined the discord, where to start and create file?

Hi @tobySolutions, can you assign this issue to me ? I've joined the discord, where to start and create file?

Sure thing, Geoffrey!! It's all yours!!!!

Hi @tobySolutions, can you assign this issue to me ? I've joined the discord, where to start and create file?

We're in the "docs"channel on Discord. Also, do you you just have to look for the file I linked above in the issue description and go through the contribution guidelines

Hi @tobySolutions, can you assign this issue to me ? I've joined the discord, where to start and create file?

We're in the "docs"channel on Discord. Also, do you you just have to look for the file I linked above in the issue description and go through the contribution guidelines

Alright, thanks

Hi @tobySolutions
Please, could you review this PR #926

Hi @tobySolutions Please, could you review this PR #926

On it, thanks!


CMake... we are not living in the 90's, nor do we serve one master!

Try posting an actual issue instead of being an asshat

True that. I think OP's problem is something along the lines of "CMake is outdated and should be replaced", but as it stands, this issue is worded very non-constructively.

y'all cannot take a joke lmao

@ShrootBuck GitHub issues are a place where people try to solve actual problems with the software. An occasional joke in a reply side note is fine, but when a whole issue is built around a joke, it becomes obstructive.


Support legacy junit xml from pytest

Recently importing this Junit XML file https://github.com/SatelliteQE/betelgeuse/blob/master/sample_project/results/sample-junit-result.xml failed with the traceback:
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/site-packages/celery/app/trace.py", line 385, in trace_task
    R = retval = fun(*args, **kwargs)
  File "/app/ibutsu_server/tasks/__init__.py", line 30, in __call__
    return super().__call__(*args, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/celery/app/trace.py", line 648, in __protected_call__
    return self.run(*args, **kwargs)
  File "/app/ibutsu_server/tasks/importers.py", line 76, in run_junit_import
    for testsuite in tree.testsuite:
  File "src/lxml/objectify.pyx", line 231, in lxml.objectify.ObjectifiedElement.__getattr__
  File "src/lxml/objectify.pyx", line 450, in lxml.objectify._lookupChildOrRaise
AttributeError: no such child: testsuite

This appears to be due to a legacy pytest xml version https://docs.pytest.org/en/stable/reference.html?highlight=junit#confval-junit_family.
Ideally we should support both. At the very least we should specify which XML version we support.

That MR I have open should solve this issue.

Fixed in #150


[Q] Clarification on the implementation of hyperband algorithm in Sweeps

Hello,
I was reading the documentation about the Hyperband algorithm in Sweeps. In the original paper, each bracket refers to an implementation of Successive Halving Algorithm (SHA). However, in the documentation, it says that a bracket is one pre-set iteration counts. I am confused what the iteration is referring to and how the Hyperband works in sweeps.
In the cases where I have max_iter=150, eta=3, and s=4, the early stopping will occur based on the epochs [150/3, 150/9, 150/27, 150/81] and the thresholds calculated based on these epochs, as seen in the source code.
My question is that when I looked at the code, I find SHA is applied only once rather than multiple times. How is SHA implemented in the W&B version of Hyperband?
Also, is the hyperband implemented serially or parallelly?
If serial and the history of different runs are necessary to decide early stopping, does it mean that the first run will never be pruned?
And if it is parallel such that every run is ran for a set epoch and then compared, how does this fit with Bayesian Gaussian processes which require the hyperparameters in each run to be sampled from previous run results?
Thank you.

@scho97 apologies for the delay here.
Our implementation is based on the "distributed implementation" idea briefly discussed in the conclusion section of the paper. And, eta, and s define the brackets when hyperband algo should consider stopping runs based on all the other runs at that same iteration number.
Also, in our default implementation of starting & running sweeps, the early stopping criteria is serialized and not parallelized. However, you can do some configurations on your end and launch multiple runs in parallel yourself. Here's our guide on how to launch multiple runs from a sweep.
So, once the first run logs your_optimization_metric [150/3] times, the first bracket is setup. Now, the next run when it logs your_optimization_metric 50 times, it will be compared to this bracket, and similarly at [150/9] iterations & for all future runs.
A good way to see what is happening is to run in "local" mode with full debugging: wandb sweep --controller --verbose sweep-grid-hyperband.yaml. This will give you insight into how your bands are setup and what they are set at.
Finally, this means that our sweep monitor service will monitor all your runs, and it will stop any run where the metric you are optimizing (specified in your sweep-grid-hyperband.yaml file) is in the bottom half of all other runs which reported that metric at the same iteration. When you run the sweep controller locally, it will show you what those bands are computed to as the sweep is executed.

Hi @scho97, I wanted to follow up on this request. Please let us know if we can be of further assistance or if your issue has been resolved.

Hi @anmolmann, thank you for your reply.
Firstly, I thought the first bracket sets up once the first run logs the metric [150/81] times, as the bands (i.e., bands=[150/3, 150/9, 150/27, 150/81] here) are sorted.
I am still confused how the idea of bracket in the paper fits into the ones implemented in wandb. Are you saying there will be n=len(bands) brackets or there will be one bracket in which each run is compared at [150/81] iterations, [150/27] iterations, and so on.
As for the "local" mode, I will try it out and monitor how the bands are setup. Thank you.

@scho97 Brackets are configured at static iterations for a specified metric (where an iteration is the number of times a metric has been logged — if the metric is logged every epoch, then there are epoch iterations). So, there will be 4 brackets in this case: [150/3, 150/9, 150/27, 150/81] and each bracket will have respective bands (max_iter/eta). So, at a specific iteration: active runs will be compared against all other runs at that iteration to determine which should be stopped.
Also, did you try out the local mode and see how the bands are setup in your case?

Hi @scho97, I wanted to follow up on this request. Please let us know if we can be of further assistance or if your issue has been resolved.

Hi, following up on this, the wand implementation is just very unrelated to the algorithm proposed in the hyperband paper, right?
The paper addresses the tradeoff between "how many parameter settings can i try" and "how long can I evaluate each setting".
The wandb implementation, however, doesn't address the "how many parameter settings can i try" question, but only provides checkpoints at which early stopping is applied with regards to earlier runs. Therefore, the concept of brackets in wandb-hyperband and actual hyperband is something else, correct?


Add integration test in the CI pipeline

Add a test for the entire pipeline (preprocessing + training).

Duplicate of https://github.com/DeepRank/deeprank-gnn-2/issues/95


K8SSAND-1511 ⁃ Remove templating when deploying CRDs in e2e tests

We currently rely on some Go templates in our e2e tests. Typically, the e2e test framework will first create a kustomization file using Go templates, then invoke kustomize build | kubectl apply on it.
This is currently done mostly to cope with dynamically generated data. More specifically, it is done to:

Change namespaces (since they are randomly generated);
Change image and tag names (when running the test against a specific image instead of latest);
Change the name of ingress routes and the target hosts (for Stargate and Reaper API tests);
Change fixtures: this is by far the heaviest templating. Templates are used to change:

k8s context names (the default ones are valid for Kind local clusters, when running on cloud providers they need to change)
topology zone names (the default ones are valid for Kind local clusters, when running on cloud providers they need to change)
enable / disable host networking (host networking is enabled by default for Kind clusters to work properly, but it should be disabled on cloud providers)
storage class names (the default one is for Kind clusters)

We would like to remove this templating because it makes it hard for the user to understand what resources are actually being deployed, and makes the fixtures less useful as self-contained examples. Also, the templates themselves are hard to maintain.
All the above could be replaced with static kustomization files and a few changes. I will outline my suggestions below:
Namespaces
Instead of using generated namespaces I suggest that we use fixed namespaces. The namespace for the fixtures should simply be the fixture name itself, so if a fixture is called "multi-dc-reaper" then its namespace will be multi-dc-reaper.
The namespace will be created as it is created currently, that is, programmatically at the beginning of the test. Note: the fixture namespace will also be used for deploying the operator itself (except for cluster-scoped deployments).
Fixtures and Test profiles
I suggest that we consider the fixture folder and its CRDs as the kustomization base to apply.
I also suggest that we create the notion of "test profiles", that will correspond to kustomization overlays for different environments.
Finally, I suggest that each fixture should contain subfolders for the control plane and each data plane. This allows different resources to be deployed in the right context.
See an example below of the typical layout of a fixture folder.
Regarding test profiles:

The default test profile would be "kind-local", and there would also be at least another test profile, "gke".
At this point imo we don't need a "gha" test profile, but this could be introduced later, to kustomize things such as heap sizes, etc.
The test profile can be changed via a flag.
Each test profile would materialize as a kustomization overlay, in a a subfolder inside each fixture folder.

The "kind-local" profile could e.g. turn on host networking, which could consequently be removed from the base fixture CRD itself (since it's not required on actual clusters, only on Kind local ones).
The "gke" profile could e.g. change the context names, the zone names, and the storage class name to match GKE standards.

Image names
Image names usually don't need to be changed for local and GHA testing. However it needs to be changed for GKE if we want the test to fetch a custom image that was just built and pushed to GCP Artifact Repository.
Image names for GKE will then be kustomized through the gke test profile / overlay.
Another usage of custom image names is ad-hoc testing. For such cases, I suggest that the tester modify the test profile manually and specify the desired image.
Context names
Context names will be kustomized through test profiles / overlays.
I suggest using fixed context names for GKE, such as gke-k8ssandra-0, gke-k8ssandra-1, etc. which then would map one-to-one to default ones: kind-k8ssandra-0, kind-k8ssandra-1, etc. This means the context names need to be created or renamed in the kubeconfig file with the appropriate names prior to running the test.
Zone names
Zone names will be kustomized through test profiles / overlays.
I suggest that for GKE, the affinity labels be changed from the default one topology.kubernetes.io/zone to another one, e.g. k8ssandra.io/rack. This is because the default label is tightly coupled to AZ names and this is not portable from a cluster to another. Using another, proprietary label enhances the portability of fixtures. Of course, GKE nodes will need to be adequately labeled prior to deploying the fixture.
Host networking
Host networking will be kustomized through test profiles / overlays. I suggest switching off host networking in the base fixtures, and turning it on only for the kind-local test profile / overlay.
Storage
Storage will be kustomized through test profiles / overlays.
Ingress routes
Ingress routes will be made part of the fixture set, instead of being deployed programmatically. This can be done now that #523 made Traefik a prerequisite.
The example routes will be kustomized for each test profile / overlay, and for each data plane. The kustomization will change the route matching rule and the target service name.
One problem that we have is that the current routes use a Host rule that matches the entire host name. That includes the IP of the endpoint, which is not portable. I suggest using HostRegexp instead, which allows us to have one rule match any external IP, e.g. :
HostRegexp(`reaper.my-fixture.{ip:[0-9\\.]+}.nip.io`)I also suggest that we change our nip.io URLs to include the fixture name / namespace, e.g. `reaper.my-fixture.W.X.Y.Z.nip.io`. This will reduce the risk of interference between tests.

Stargate config maps
These are currently deployed programmatically. I suggest that they be incorporated into the fixture set and deployed in each data plane.
Encryption secrets
These are currently deployed programmatically. I suggest that they be incorporated into the fixture set and deployed in each data plane.
Example of a fixture folder layout
The general layout of a fixture folder is as follows, assuming that my-fixture is a multi-cluster test with 2 data planes:
my-fixture
├── control-plane
│   ├── base
│   ├── components
│   └── overlays
├── data-plane-0
│   ├── base
│   ├── components
│   └── overlays
└── data-plane-1
    ├── base
    ├── components
    └── overlays

At the beginning of each test, the E2E framework would do the equivalent of the following commands:
cd my-fixture
kustomize build control-plane/overlays/$TEST_PROFILE | kubectl apply --context $CONTROL_PLANE -f
kustomize build  data-plane-0/overlays/$TEST_PROFILE | kubectl apply --context $DATA_PLANE0 -f
kustomize build  data-plane-1/overlays/$TEST_PROFILE | kubectl apply --context $DATA_PLANE1 -f

This is the full layout of that fixture folder; assuming that it deploys a K8ssandraCluster in the control plane, and also deploys ingress routes for Reaper and Stargate, as well as Stargate config maps, in all data planes:
my-fixture
├── control-plane
│   ├── base
│   │   ├── k8ssandra.yaml
│   │   └── kustomization.yaml
│   ├── components
│   │   ├── gke
│   │   │   ├── contexts
│   │   │   │   └── kustomization.yaml
│   │   │   ├── image
│   │   │   │   └── kustomization.yaml
│   │   │   ├── storage
│   │   │   │   └── kustomization.yaml
│   │   │   └── topology
│   │   │       └── kustomization.yaml
│   │   └── kind-local
│   │       └── host-networking
│   │           └── kustomization.yaml
│   └── overlays
│       ├── gke
│       │   └── kustomization.yaml
│       └── kind-local
│           └── kustomization.yaml
├── data-plane-0
│   ├── base
│   │   └── kustomization.yaml
│   ├── components
│   │   └── ingress
│   │       ├── reaper
│   │       │   └── kustomization.yaml
│   │       └── stargate
│   │           └── kustomization.yaml
│   └── overlays
│       ├── gke
│       │   └── kustomization.yaml
│       └── kind-local
│           └── kustomization.yaml
└── data-plane-1
    ├── base
    │   └── kustomization.yaml
    ├── components
    │   └── ingress
    │       ├── reaper
    │       │   └── kustomization.yaml
    │       └── stargate
    │           └── kustomization.yaml
    └── overlays
        ├── gke
        │   └── kustomization.yaml
        └── kind-local
            └── kustomization.yaml

Admittedly, this is a lot of kustomization files, but I think this is the price to pay to get rid of templating entirely.
┆Issue is synchronized with this Jira Task by Unito
┆friendlyId: K8SSAND-1511
┆priority: Medium

@adutra take a look at this model that was created for cloud-readiness and currently being used.
I wonder if this would be an alternative way to solution your test inputs, dynamic values, etc. for e2e tests?  It uses a similar approach but with Golang structures instead of kustomize test fixtures.   The models were created to manage not only TF provisioning, but for k8ssandra installation as well.  Same model, two different activities that are decoupled from one another.

@jeffbanks thanks I will have a look 👍 There is definitely some overlap here, especially around the deployment of the operators. However the idea here is to also change how we deploy the test fixtures themselves, which is something that cloud-rediness is not supposed to support (unless I'm missing something).

I have a working prototype that works on my machine, see #546 . The only test that works for now is RemoveTemplating, but I'm able to deploy a multi-cluster fixture with all the ingresses correctly configured.

the fixture namespace will also be used for deploying the operator itself (except for cluster-scoped deployments).

In fact, I think this won't be possible. The operator is deployed by building the config/deployments dir, and the namespace is k8ssandra-operator. I think we'll need to always deploy the operator in cluster-scope mode (install in k8ssandra-operator and watch all namespaces).

In fact, I think this won't be possible.

@adutra what won't be possible, deploying the operator in a different namespace when it is configured to only watch a single namespace? If that is the case, then that is a bug that needs to be fixed, separate from this issue of course.

There shouldn't be an issue with deploying the operator in the fixture namespace. I did a quick sanity check. It should just be a matter of using a namespace transformer in the kustomizations at this level:
my-fixture
├── control-plane
│
│
│
├── data-plane-0
│
│
│
|── data-plane-1

I was thinking about including k8ssandra.yaml in the control-plane kustomization. That may not work, at least not without some changes. A lot of the tests set the k8sContext property. That requires the ClientConfigs to be deployed. We cannot generate the ClientConfigs until the operator is deployed. If we try deploying k8ssandra.yaml along with the operator the validating webhook should reject it since we won't yet have a ClientConfig.  I have mentioned in other discussions that I don't think the k8sContext check should be performed in the webhook. I think it should be handled with a status condition, maybe something like ValidConfiguration for example. This could work but it creates a lot of noise in the operator logs which can could make debugging harder.
I think it would be better to keep the fixture deployment separate. We should

Deploy the operator in the control plane data plane
Create ClientConfigs
Check that the operator is ready
Deploy the fixture

I think this is more or less the steps we have in place today, but we should push as much as we can out of Go code and instead do it declaratively.
For the context names why not just keep the same whether we are running against kind, GKE, or something else? Wouldn't that keep the test code simpler? I want to err on the side of simplicity as much as possible :)
I want to suggest another approach for host networking and storage. We have had #63 open for some time now. The idea with the operator configuration is to supply various settings and defaults via a ConfigMap. cass-operator already does this for images. For dev/test environments running with kind in particular we could specify that host networking should be enabled by default. This would save having to declare it in each K8ssandraCluster manifest. Similarly, we could specify a default storage class to be used. This would simplify configuring the fixtures and would also be generally useful outside of tests. wdyt?

There shouldn't be an issue with deploying the operator in the fixture namespace. I did a quick sanity check. It should just be a matter of using a namespace transformer in the kustomizations at this level:

Yes that would work, but I'm reluctant to add one more kustomization file just to declare a namespace transformer. Moreover, as you pointed out, that kustomization file needs to be applied when deploying the operator, while the others are meant to be applied when deploying the fixture. We would need to create a specific subfolder for that, maybe:
my-fixture
├── operator-deployment
├── fixture-deployment
    ├── control-plane
    ├── data-plane-0
    |── data-plane-1

That said, I wonder if we couldn't just deploy all the fixtures in the k8ssandra-operator namespace? (Except the cluster-scoped ones of course.) This would greatly simplify the deployment phase and spare us the creation of one extra namespace.

For the context names why not just keep the same whether we are running against kind, GKE, or something else? Wouldn't that keep the test code simpler? I want to err on the side of simplicity as much as possible :)

That would work too, but with one caveat: the contexts created with Kind won't get automatically deleted when you run kind delete clusters --all. We can add an extra step in some makefile targets to work around that. If that's ok for you, then I'm in.

I want to suggest another approach for host networking and storage. We have had https://github.com/k8ssandra/k8ssandra-operator/issues/63 open for some time now. The idea with the operator configuration is to supply various settings and defaults via a ConfigMap.

I agree with the idea to use a ConfigMap to configure the operator itself. I'm a bit reluctant about doing so to modify user objects. What makes me uncomfortable is that we would be modifying resources without telling the user what and why. All in all, I think I still prefer the verbosity of a kustomize-based solution.

Deploying all fixtures to the k8ssandra-operator namespace would certainly simplify things; however, it would be good to have at least one test that does deploy to a different namespace to verify deploying into a different namespace does work correctly.

Fair enough, let's deploy to a different namespace then.

For what it's worth I always use kind delete clusters --name . Will that still work?

The command will work, the resources will be deleted, and the cluster entry and the user entry will be deleted from your kubeconfig file; but the context entry will remain in your kubeconfig file (and will become invalid since it would point to a non-existent cluster and a non-existent user). I don't think it's a huge problem tbh, but something to be aware of.

We would be applying default values. We already apply default values via kubebuilder annotations. This gives us a way to change what those defaults would be at runtime. This would only apply for setting defaults. It would not modify existing clusters.

OK, then I agree to use it for, say, image defaults. But for hostNetwork we would still have a problem imo. The field is a bool; it is thus impossible to differentiate the two definitions below:
spec:
  cassandra:
    networking:
      hostNetwork: false #explicitly set to false

spec:
  cassandra:
    networking: {} # implicitly set to false (default value)

In the first snippet, should the operator override hostNetwork, even if it was explicitly set to false? It doesn't sound right to me. Moreover, not all deployments need hostNetwork true with Kind clusters, only multi-dc ones.

host networking and storage I am proposing that they be done for https://github.com/k8ssandra/k8ssandra-operator/issues/63 independent of this ticket

OK so I suggest that for now we add kustomizations for these settings, and in #63 we can revisit that later.

The hostNetwork property is a bool, but the Networking property is a pointer.

That doesn't change much the situation I'm afraid. What if the user wants to specify nodePort ? That is, how would you distinguish the following snippets?
spec:
  cassandra:
    networking:
      nodePort:
        native: 9142
      hostNetwork: false #explicitly set to false

spec:
  cassandra:
    networking:
      nodePort:
        native: 9142
        # hostNetwork implicitly set to false (default value)

But let's table that for now and come back to it when implementing #63.

As discussed in a team meeting 2 days ago, we are going to table this for now until we get a clear vision of what we want to achieve wrt to running tests in the cloud.


remove url listener on promise resolve

On each user login/logout there will be a new appUrlOpen Listener in the app.
This fix removes the listener on the resolve.

Good catch 👍


faker 1.9.5 has wrong version info (1.9.4) in version.rb and Gemfile.lock

grep '1.9.4' Gemfile.lock CHANGELOG.md lib/faker/version.rb
Gemfile.lock:    faker (1.9.4)
lib/faker/version.rb:  VERSION = '1.9.4'

Seriously? Will fix it.

Fixed @bill-e-ghote


Use yq image from quay

...to get around shiny new docker rate limiting problems.

Closing in favor of #457


Add a way to enforce DTLS session expiration

Remember to update copyright header in those modified files, just bump year.


a function that causing...

maxthon:<IP_ADDRESS>0
YouTube Center Developer Build v492
this is the function:

normal:

when it open:(i think there is no such recommdation anymore...)

The option is hiding the right sidebar which contains recommended channels as it should. Unless you can be more specific I cannot see the display error you mention.


[Bug]: Text Content overlapping with the container-box

Give a brief about the bug ✍
After we go in Tutorial page we can see the heading text is overlapping with container box is not a good thing

What is the expected behavior? 🤔
We can put that heading to top of the page so that will not overlap each other
Provide step by step information reproduce the bug 📄
Description
Select program in which you are contributing
No response
Code of Conduct

[X] I follow CONTRIBUTING GUIDELINE of this project.

Please asssign me this issue