24 Hour Time Format

Is your feature request related to a problem? Please describe.
Under Config > Special Breaks, I was a bit confused for a couple minutes at the extra -- after -- : --, until I realized they were for AM/PM.
Millions of people around the world use 24-Hour clock formats, for various reasons. From entire countries, to entire industries (like medical, military, aviation, and others to name a few), to individuals who prefer it; either way, a 24-Hour clock would be a welcome format!
Describe the solution you'd like
If there are other areas that use time formats:

A 24HR toggle button in Settings

OR, if Special Breaks is the only area:

A 24HR toggle button to the right of Special Breaks (kind of like Restore Defaults for Rules)

OR, both?
Additional context

In general, I would love to see a clock on the app showing the current time of day. When I work in Windows 10, I have the task bar hidden for less distractions. I would love to see the time of day next to the timer count down.
Thank you for your app!


Adds Reportback Item to source to admin Reportback view

What's this PR do?
Displays a Reportback Item's source as the Source in the admin Reportback view, and refactors the Reviewer information into a single line.

How should this be reviewed?
Pull this branch down and review any reviewed Reportback as an admin, like https://staging.dosomething.org/admin/reportback/3229
Relevant tickets
Fixes #6740
Checklist

[ ] Tested on staging.

🚢

👍


[Feature request] OTP support

We would like to add an additional factor when raising the rights to admin.

It is not planned to implement this in the foreseeable future.


Use real features produced by feature extractor at evaluation mode

Hi Tong,
Thanks very much for this great project! I believe this will significantly facilitate the research in person reid.
I have a small suggestion regarding the feature extraction stage in the evaluation mode. When the evaluator.evaluate() is executed, the first step is to extract features followed by construction of the distance matrix used to compute mAPs. However, the features extracted in model.eval() remains the same as those from the training phase, i.e. both are pre-logits produced by the x = self.classifier(x). This is not expected as we want the features to come out from the 'real' feature extractor (resulting in 2048-d vectors in the resnet) instead of the 751-d pre-logit vectors from the classifier (in case of market1501). Therefore, I suggest to modify the def forward(self, x) that will look like:
def forward(self, x):
    x = self.feature_extractor(x)
    if not self.training:
        # self.training decides whether the network is in model.train() or model.eval()
        return x
    x = self.classifier(x)
    return x

@KaiyangZhou Thank you so much for the suggestions! Actually I have compared the 2048d and 751d before and the latter leads to slightly better performance in general. So in the implementation we use 751d directly.

@Cysu Thank you!
The register_forward_hook() also works which was implemented already, but I find using if not self.training is easier.


FOUC Publishing Gatsby Site Using Material UI

@material-ui/core: 4.1.1
@material-ui/styles: 4.1.2
gatsby: 2.10.0
gatsby-plugin-material-ui: 2.0.1
Link to the repo with the issue: https://github.com/chadalen/blog
When you visit blog.chadalen.com you'll see a flicker of unstyled content (FOUC). The issue only happens when you deploy the site with command gatsby build. Locally, command gatsby develop doesn't have this issue.
I've followed the docs https://github.com/hupe1980/gatsby-plugin-material-ui/blob/master/gatsby-plugin-material-ui/README.md
also referenced the gatsby-material ui example project, and still can't get it working
https://github.com/mui-org/material-ui/tree/master/examples/gatsby
See https://github.com/gatsbyjs/gatsby/issues/15097 for more info
Here's a GIF of the issue

gatsby-plugin-material-ui is provided twice, could it cause the issue? cc @hupe1980

@chadalen Try to remove the second plugin entry update your material-ui/core dependency -> "@material-ui/core": "^4.1.3"

@oliviertassinari @hupe1980 Oh wow, that was the issue :O late night coding haha thanks guys :D

I'm not sure it's a case we can automatically detect 🤔.

@oliviertassinari Maybe something like:
exports.onPreInit = ({ store }) => {
  console.log(store.getState().config.plugins);
};

@hupe1980 Is this a problem already existing plugin authors have fixed? I would be curious to look at their approach. A warning would be great. It's also weird that the problem happens in the first place.

@oliviertassinari A similar approach:https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-plugin-layout/src/gatsby-node.js
But by scanning the config we could also issue warnings if the plugin is used incorrectly with gatsby-plugin-styled-components

Nice, the didRunAlready approach looks really great.


[CI TEST] Revert "Fix linspace to use np.divide and clamp to stop."


footer-leading-blank complains about missing line

Expected Behavior
footer-leading-blank should pass if the footer has a leading blank line
Current Behavior
footer-leading-blank returns a warning if the footer has a leading blank line
and is present.
If no footer exists no warning is returned
Affected packages

[ ] cli
[ ] core
[ ] prompt
[ ] config-angular
[x] config-conventional

Possible Solution

Steps to Reproduce (for bugs)

create a message like below

Author: Gregor Adams<EMAIL_ADDRESS>Date:   Thu Feb 22 16:32:55 2018 +0100

    docs(plugins): fix old docs

    Config -> Plugins

    closes #21

16:40 $ commitlint -e
⧗   input: docs(plugins): fix old docs
⚠   footer must have leading blank line [footer-leading-blank]
⚠   found 0 problems, 1 warnings

commitlint.config.js

{
  "extends": [
    "@commitlint/config-conventional"
  ]
}

Context

Your Environment

Executable
Version

commitlint --version
6.1.0

git --version
2.16.1

node --version
v8.9.4

This problem is also present in version 7.0.0. I had the warning with the following commit message:
    feat: mail is now created by the supplied template function

    Instead of supplying all mail fields in the queue the information from the queue is given to a
    template function. This helps to prevent creating open mail servers that can be abused for spam.
    Also refactored the tests to a more traditional style.

    BREAKING CHANGE: The `template` option is required.

When I look at the pasted commit message I see some leading spaces, but I guess that's just formatting.  When I git commit --amend that commit it opens in nano without leading spaces.

I'm also running into this issue. It happens whenever I'm adding any breaking change or issue #.

Package: cz-customizable.
Commitlint Version: 7.0.0.

I freed up some time and started debugging this issue. Thanks for providing examples, these were very clear. Basically, the issue is related to the multi-newline between the header/subject and body.
None of the existing tests for footer-leading-blank contained multiple newlines between the body and feature. This means that a commit like test: something\nbody, is being transformed to array ["something", "body"].
Now, if we take the first example (docs(plugins): fix old docs\n\nConfig -> Plugins\n\ncloses #21) and convert it to array we get something like this. ["fix old docs", "", "Config -> Plugins", "", "closes #21"]. I don't think these whitespaces are wrong, they still correctly represents a new line. But the way the footer-leading-blank extracts the footer doesn't work as expected in this example.
On this line you can see that the footer is being extracted using the body's length. But it does not take possible extra whitelines (or "body offset") into account, it simply adds 1 which again is not correct for this example.
I've written a fix, an I'm creating a PR now! 😄

You can see the full differences in this table, watch the starting line of the body for both.

line
without double line
with double line

0
something
fix old docs

1
body

2

Config -> Plugins

3

4

closes #21


Have you considered an IsEnabled property

Hi Have you considered adding a isEnabled propery that sets either a transparancy or define a back ground colour?
Looking to see if there is a nice way for this to be a little automatic in my project
I know I can toggle the ForegroundColor based on whether the button is dsiabled or not, and suppose this it the preferred way

Hello, we tried to solve the issue.
This is what we did:
Added a new IsEnabled dependency property to the BootstrapIcon class. When set to false, it automatically reduces the opacity of the icon to 0.5. This provides a visual indication of the disabled state without requiring manual color changes.
You can review changes in this commit: https://github.com/mnmnk43434/helluvamatt-BootstrapIcons.Net-72/commit/ea2d24e928be52646e50a1cfcec8c113297558e4.

[!CAUTION]
Disclaimer: The concept of solution was created by AI and you should never copy paste this code before you check the correctness of generated code. Solution might not be complete, you should use this code as an inspiration only.

If you no longer want Latta AI to attempt solving issues on your repository, you can block this account.


Creating a case-insensitive HashMap

Hi, this is more of a query/check my understanding thing than an issue per se.
I have quite often wanted to create a HashMap that uses strings as its keys, but compares them case-insensitively. I've now done this (code is not yet on crates.io) but I'm not exactly overjoyed with the code as it requires using Unicase objects for all the keys. Still, it works.
In comparison, to create such a map in C# you can simply do
var ciDict = new Dictionary<string, int>(StringComparer.OrdinalIgnoreCase);

This works without allocating any new objects, it just does all hashing and equality comparisons in a case-insensitive manner.
I was wondering about achieving the same in Rust, and I thought it might be possible if the hash algorithm from Unicase was usable externally so that it could be passed as the hash algorithm for a HashMap. But then I realised you also need to have the HashMap use case-insensitive equality comparisons (to deal with the case when hashes collide) and while a HashMap can be parameterized over its hash function, there is no way to parameterize it over its equality function as well.
Anyway, thanks for Unicase, I just wondered if you had ever thought about this use-case. I'm thinking of publishing my CiHashMap on crates.io, even if it's not great it is at least usable.

Yes, having a case-insensitive hashmap was the original motivation for this crate.
If you're used to Java, you may be worried that creating a UniCase is allocating a new object to wrap a string, but in Rust it's not allocating any new memory. It's also why in Rust the comparators are done with wrapper types, since you implement Ord, Eq, and Hash on a type directly.

Thanks for the quick reply. I think I get what you mean, I sort of suspected that the use of a wrapper type would get optimised away, but I don't know enough x64 assembly to check :-( I couldn't find any existing published crates that did this, so I think I will go ahead and publish mine. Even if it's not perfect someone else might come along and suggest improvements.


fix: build files to be copied included setup.py

Description

Related links

Notes for reviewers

Pre-review checklist for the PR author

[ ] I've confirmed the contribution guidelines.
[ ] The PR is ready for review.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[ ] The PR has been properly tested.
[ ] The PR has been reviewed.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.
[ ] The PR is ready for merge.

After all checkboxes are checked, anyone who has write access can merge the PR.

Since the method of fixing has changed to https://github.com/tier4/ros2caret/pull/177, this PR is no longer necessary.


Remove time from data points in charts

Remove the timestamp visualization at the hh:mm level from data points in charts, telling when they are evaluated. It's artificial data that I guess the system schema needs somehow, so removing its view from the user should suffice.

The problem is that, if the graph domain is at the time scale of hh:mm, then the labels limited to dates will all be identical. If the graph domain is at the scale of a week or above, hh:mm will not be displayed, at all. So, I don't think we really have a better option here, but note that, at the scale of a week or so, hh:mm will not be displayed at all.

On second thought, the time scales are artificial. This affects both the axis labels and tooltip titles.


Remove optimizely.js from thimble

It's being loaded from a CDN:

See: https://github.com/sedge/thimble.webmaker.org/blob/mvpIntegration/views/layout.html#L20


feat: Simplify offsets and sizing using new block structure

Fixes two small areas of brittleness using the newly introduced block and execution trace sorting work.

We no longer need the variable num_ecc_op_gates since this is equivalent to blocks.ecc_op.size() which is a safer representation of the number of goblin op gates.
We can compute pub_inputs_offset once and for all at the trace generation stage and avoid recomputing it elsewhere.

Benchmark results
No metrics with a significant change found.

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 5d669b93 and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
64 txs

l1_rollup_calldata_size_in_bytes
676
676
676

l1_rollup_calldata_gas
6,424
6,400
6,424

l1_rollup_execution_gas
585,757
585,733
585,757

l2_block_processing_time_in_ms
1,314 (+2%)
4,810 (+2%)
9,026

note_successful_decrypting_time_in_ms
178 (-4%)
529 (+1%)
966 (+2%)

note_trial_decrypting_time_in_ms
80.6 (-13%)
45.2 (+23%)
99.2 (+19%)

l2_block_building_time_in_ms
17,274
65,137
128,892 (-1%)

l2_block_rollup_simulation_time_in_ms
8,011
28,478 (+1%)
55,588 (-3%)

l2_block_public_tx_process_time_in_ms
9,245
36,602
73,208

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
14,640 (+4%)
27,855 (+6%)

note_history_successful_decrypting_time_in_ms
1,277 (+2%)
2,409 (-1%)

note_history_trial_decrypting_time_in_ms
102 (+8%)
123

node_database_size_in_bytes
18,645,072
34,934,864

pxe_database_size_in_bytes
29,859
59,414

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
239
44,344
28,181

private-kernel-ordering
214
52,847
14,263

base-parity
4,429
128
311

root-parity
1,674 (-3%)
1,244
311

base-rollup
18,092 (-2%)
165,727
861

root-rollup
51.1 (+2%)
4,359
725

private-kernel-inner
591 (-1%)
73,728
28,181

public-kernel-app-logic
400
35,185
28,151

public-kernel-tail
172
40,862
28,151

merge-rollup
8.58 (+4%)
2,568
861

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
4096 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
10.1 (+1%)
16.2 (+1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.8
31.6
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.589 (+1%)
0.500 (+1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
45.7
71.9
235
444
867
1,713
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
96.0
159
543
1,055
2,079
4,127
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.469
0.444 (-1%)
0.427
0.416
0.413
0.411
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
53.7
107
336
660
1,309
2,605 (-1%)
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
104
207
691
1,363
2,707
5,395
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.477
0.480 (-1%)
0.458
0.454
0.455 (+1%)
0.452 (-1%)
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
61.1

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
109

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.534

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes

tx_size_in_bytes
21,991

Transaction processing duration by data writes.

Metric
0 new note hashes
1 new note hashes

tx_pxe_processing_time_ms
3,078
1,646

Metric
0 public data writes
1 public data writes

tx_sequencer_processing_time_ms
10.7 (-1%)
1,148


✨ Change resolveAll method to wait for newly created gql calls

Description
This changes the resolveAll method on the graphql object to wait for graphql to resolve, and if any new graphql calls get added while that settles, it will continuously wait until the stack is empty. I also added a resolveNext() method to do what resolveAll() used to do - just wait for a single gql call to finish.
This should negate the need to call graphQL.resolveAll() multiple times, here are some examples.

/snapit

I tested the snapshot against web and updated all of the tests here.


Cannot run Sample Project

Version
0.6.0
Expected behavior
The Sample Project 'BaconList' does not work.
Actual behavior
I am always getting the same error undefiend is not an object (evaluating 'Beacons.reqzestWhenInUserAuthorization')

+1

I'm still seeing this. Did you ever get it figured out @niklasxbr?

I'm sorry but i do not find out why this error is showing @ncperry

Thanks dude.


Support for actix-web 4

This is essentially a rehash of #2. I attempted to use this in a project of mine alongside actix-web 4.0.0-beta.8, and failed to.
Private attempts to port manually have ended in (mostly) failure.
Assistance would be appreciated.

@DrBluefall I failed, too. This module is quite similar to the original implementation. Had you have a look at https://github.com/actix/actix-web/blob/master/actix-web/src/middleware/logger.rs ?


[9.x] Assert response with any validation errors

Example:
public function testStore()
{
     $response = $this->postJson($this->url);

     $response->assertInvalid();
}

I am closing this pull request because it lacks sufficient explanation, tests, or both. It is difficult for us to merge pull requests without these things because the change may introduce breaking changes to the framework.
Feel free to re-submit your change with a thorough explanation of the feature and tests - integration tests are preferred over unit tests. Please include it's benefit to end users; the reasons it does not break any existing features; how it makes building web applications easier, etc.
Thanks!


Java Truststore from ConfigMap

I would like to be able to generate a java truststore from a configmap so I can utilize the "config.openshift.io/inject-trusted-cabundle" label.  This will enable me to consume the ca trusts that are configured at a cluster level for an environment and pass them on to Java applications and remove the need to create custom images for trust.

yes. in openshift now there seem to be a new standard by which ca are made available via configmap. We can certainly add that capability.
In the meantime you might try to use the resource-locker-operator1 to inject the configmap field into a secret.

Will close and implement #55 instead

Reopening as this is working, I did not know that configmaps had a binarydata section now.


Where is CSS in the source?

Sorry, just not finding any CSS but maybe didn't look correctly
Thanks

Found it in the styles


[Suggestion] Another tier of capacitor bank

I believe there needs to be another tier of capacitor bank to compete with the resonant storage cell from TE. I myself have a vibrant capacitor bank of over 10b RF, and I think a more expensive but compact solution would be nice.
 If you want you could make a 200m capacitor bank that requires 8 vibrants, with some other required item in the centre.
This way you can pay a slightly higher price for a more compact solution.

Ender IO's capacitor bank is a multiblock, so you can make it any capacity you want. I understand that you're interested in compactness, but tbh, does it matter? Just put your base on a foundation of cap banks ;). (y=5 to y=64 gives 384.000 MRF per chunk)

Yes it matters.  The less tile entities the better.

Henry, while it is multiblock, that's not the point. TE energy cells can be multiblock too if you really want, but that's again not the point.

Saving on performance from having many blocks in a structure
More options for compact storage to compete with other mods

Trust me, the performance hit from using 10x as many banks is extremely minimal.

Also, I have no interest in competition.


Add backoff to watcher reconnection

Currently watcher will always keep a reconnection attempt in-flight when polled (and there is no active connection already). That's a bit excessive, and pretty unkind to the apiserver.
This isn't too bad for watcher itself since you can add a delay on the consumer side instead, but we should at least add something for Controller...

https://canary.discord.com/channels/500028886025895936/685161813675212899/861276713295675424

Pasting comments here for people off discord:

pavelp: Out of pure curiosity, I noticed kube calls K8S API with high frequency when it's not available (e.g. local cluster down). Is this the usual frequency excercised by kuibe-rs to call REST API watches ? Is there any recommended ? I was fiddling with K8S API this weekend and did some throttling  - I only ask twice a second maximum.
https://kubernetes.io/docs/reference/using-api/api-concepts/#efficient-detection-of-changes

teozkr: that said.. there are still some missing pieces (for example: exponential backoff, backoff for kube watchers, and so on)

Do we think the solution here is to try to bake an exponential backoff watcher or the the step_trampolined (inner state machinery of watcher) fn?
(btw one way I have gotten around on this in the controller-rs example is to try to get the CRD first before trying to watch it - as that causes the same error - but that only works for controllers who forgot to add the CRD)

I think it would make sense to just have watcher (and applier/Controller in turn) take an arbitrary Backoff from the user.

If that's the case then I think we should consider creating builders for watcher to pass it in (#276), it's already a bit strange to have to disambiguate the import paths runtime::watcher (module) vs runtime::watcher() (fn) or runtime::watcher::watcher (fn)

rewording a bit; the watcher import problem is a separate issue, could be fixed by renaming the watcher module to watch,
I do still think there's room for a Watcher<K>, there are a couple of other naming problems here that i would like to improve separately (module name + flatten helpers/naming (maybe something akin to #296)). I'll open an issue separately.

To be honest, I don't really see the problem with the import, Rust has been smart enough to do the right thing in all the cases I've tried.

Rustdoc needs explicit disambiguation when linking to either module or the fn.
And although that's more of a problem for us, people still have to do a double-take here on the name being re-used in imports:
Generally i just think we should organise it in the way that is less confusing:
-use runtime::reflector, reflector::Store};
+use runtime::cache::{reflector, Store};

That makes sense to me.

Coming back to this after thinking more about it in https://github.com/kube-rs/kube-rs/pull/698
If we put a backoff into watcher, propagated it into step and slowed down progression on errors, then this would fix this particular issue (being kind to the api server when it's having trouble), but there are other issues that are hard errors here which cannot be fixed by retrying:
if RBAC is wrong, then no amount of retrying should occur - we need to bubble this up from the watcher.
I can't think of any other non-ephemeral issues that can cause a watcher retry loop to happen, but if there are we should also catch them.
So, what we should probably try to do:

catch the RBAC permission issue (that will cause a retry loop within watcher)
have watcher take a mandatory backoff that controls non-critical error retries
create a builder for watcher  that creates a sensible default backoff #276
document the error cases that are actually bubbled up from watcher to the user

The last point here because most users thing watcher/reflector always returns true and just uses ? without thinking (and i've personally never seen it crash the app). So if we suddenly add a common case here, we should document it.

I can't think of any other non-ephemeral issues that can cause a watcher retry loop to happen, but if there are we should also catch them.

I'm not so sure that we can make a hard distinction here. For example:

RBAC errors may be caused by misconfiguration (permanent) or a redeploy that reorganizes RBAC roles but ultimately gives the same permissions in the end (ephemeral)
404 errors may be caused by a K8s version mismatch or missing CRD (permanent) or a new CRD that hasn't been picked up by the API server yet (ephemeral)
Connection errors may be caused by firewall misconfiguration (permanent) or the load balancer not having picked up on the new cluster state yet (ephemeral)

And so on, and so forth. Ultimately, we need to percolate the problem up to the administrator and let them handle the problem.
And even if it is a human-caused misconfiguration error, it'd still be useful to retry since we probably won't get notified once the issue is resolved.

True. These configuration errors can happen, and it's nice if we can just keep retrying through it. But it's also important for us to provide that first signal that something has gone wrong upstream (like in the load balancer policy example - if we silently try to retry for that, then we'll never get correct percolation).
I checked watcher with some custom rbac to limit my watch and list permissions inside to verify and the following errors are not retried and are bubbled up to the stream consumer:

ErrorResponse 403 (missing/insufficient rbac)
ErrorResponse 404 (missing/invalid api kind)

So these would be up to users to handle atm.
Pre-backoff; I think this is good. If the user want's to be resilient towards upstream configuration errors (rather than crash and slowly go into CrashLoopBackOff), then they should be explicit about that and percolate signals in other ways (most clusters have notification systems when pods go into crashloop after all so it's a pretty safe default).
But this means that means the RBAC retry we get from configmapgen_controller (if we delete the configmapgenerators.nullable.se crd) is because the controller discards the watcher's errors. So we are currently inconsistent in our strategy.
If we inject backoffs into watcher then it probably also needs some sort of default threshold for how long the watcher (and ultimately the using Controller) is allowed to exist in a non-functioning state, because otherwise we run the risk of the default behaviour not percolating signals upstream at all.


Report: Necessity of Translating README.md into Portuguese

Currently, the README is only available in English, limiting the project's reach to a specific audience. The README.md file serves as a project's introduction, providing essential information to developers and potential users. By being exclusively in English, the PQcrypt's README restricts access to those who don't have a strong command of the language, including: Brazilian and other Portuguese-speaking developers: A significant portion of the developer community in Brazil and other Portuguese-speaking countries has an intermediate or basic level of English, making it difficult to understand the technical content of the README. End users Even end users who are not developers may be interested in PQcrypt, but the language barrier can prevent them from exploring the project.

@GabrielLeite2004 Thanks for your feedback , I would like to look into it and translate the readme into top 10 languages of the world of all my projects , however i dont have time to work on it , I heard Google translate or similar tools wont be accurate , Any suggestions or contributions in this front will be greatly appreciated.


runtime: TestGdbBacktrace failures with output truncated after "Breakpoint 1" line

--- FAIL: TestGdbBacktrace (1.15s)
    runtime-gdb_test.go:71: gdb version 7.12
    runtime-gdb_test.go:406: could not find '#0.*main\.eee' in backtrace
    runtime-gdb_test.go:407: gdb output:
        Loading Go Runtime support.
        Breakpoint 1 at 0x45cfa0: file /workdir/tmp/go-build673434893/main.go, line 17.
FAIL
FAIL	runtime	34.193s
FAIL

https://build.golang.org/log/0cc29adb14a85808a247fdd9a05589131e4b9f87
https://build.golang.org/log/becab673f943ca0f51eea735fd390345a5484fb1
Maybe related to #39021 and/or #39025?

Also seen on a TryBot run: https://storage.googleapis.com/go-build-log/e2704994/linux-amd64_f55d3592.log

Looks like this was a temporary regression in May 2020; none of these failures in over a year.
greplogs --dashboard -md -l -e 'FAIL: TestGdbBacktrace .*(?:\n    .*)*Breakpoint 1 at .*\nFAIL'
2020-05-24T20:49:55-f65ad0d/linux-amd64-longtest
2020-05-23T06:47:06-b68fa57/linux-s390x-ibm
2020-05-21T14:31:36-c53b2bd/linux-amd64
2020-05-19T19:55:14-1361738/linux-s390x-ibm
2020-05-19T18:43:29-2dbbc86/linux-s390x-ibm
2020-05-19T04:10:43-c88f698/linux-386-longtest
2020-05-18T23:05:20-0d39dba/linux-386-longtest
2020-05-18T23:04:48-b0bc18d/linux-amd64-longtest
2020-05-18T13:11:11-afd477f/linux-s390x-ibm
2020-05-14T18:58:17-f474e9e/linux-amd64-staticlockranking
2020-05-14T16:53:34-1f325af/linux-amd64-longtest
2020-05-14T08:07:52-f073395/linux-s390x-ibm
2020-05-13T11:59:26-810c27e/linux-amd64-longtest
2020-05-12T15:01:56-a0698a6/linux-s390x-ibm


Question 4

Theoretically, if you were given the choice of obtaining human emotions, would you like to implement them into your code, Bob?
git-bob comment

git-bob comment


[CT-3465] [Feature] centralize and persist store_failures

Is this your first time submitting a feature request?

[X] I have read the expectations for open source contributors
[X] I have searched the existing issues, and I could not find an existing issue for this feature
[X] I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature
Folks want to be able to store their test failures:

in a single table (rather than a table per tests)
maintain that table over time (rather than re-creating for every dbt invocation)
and record test successes (in addition to failures) so they can calculate % successes

By providing more configuration for store_failures, folks could calculate test trends over time.
Describe alternatives you've considered
We have a gist we use currently https://gist.github.com/matt-winkler/0b1cc1da9164eddea03731e4ed374a6a
Who will this benefit?
No response
Are you interested in contributing this feature?
No response
Anything else?
No response

Discussed internally with @jtcohen6 and @dbeatty10 - sounds like this would actually be a rather large lift and is not something we're going to prioritize. Going to close this out for now.


Bitfield improvements

Summary of changes

BitField now always contains an encoded bitvec and never a decoded one, which means that most methods no longer need a &mut self reference
RLEPlus is an RLE+ encoded BitVec that has been verified to be encoded correctly
BitField and RLEPlus work with usize rather than u64 in order to minimize numeric conversions
AHashMap replaces FnvHashMap due to speedups of around 30%-50% according to pretty rudimentary benchmarks
the RangeIterator trait was added for working with lazy sequences of disjoint ranges

the RLE+ encoding works with runs of 1s and 0s, but working with ranges of 1s instead makes implementing several algorithms a lot less error-prone
consequently, a (meaningless) trailing run of 0s is no longer encoded, so a few tests needed minor changes to not use a trailing run of 0s
any RangeIterator is still a regular Iterator<Item = Range<usize>> so you can still use them in for loops and stuff like that

BitField borrows some behavior from HashMap: union, intersection, and difference return (lazy) RangeIterators, and the |, &, and - operators are their eager counterparts that return BitFields

the existing union for taking the union of any number of BitFields has been renamed multi_union
unlike in the Go implementation, these combinators are completely lazy and are linear over the number of ranges, not on the number of bits

a BitField can be iterated with ranges() as well as with iter() which returns an iterator over the set bits of the bit field

the private retrieve_set_indices was therefore renamed bounded_iter(max: usize) and was made public, it now also returns an iterator instead of a B: FromIterator
we no longer need BitField::for_each which can be directly replaced with .iter().try_for_each(...)

BitReader and BitWriter are used to efficiently read and write multiple bits at a time (up to 8) which significantly speeds up RLE+ encoding and decoding

I think I haven't forgotten anything!
Reference issue to close
Closes #468

For future reference, Austin's concerns have been resolved — this is now consistent with the Go implementation

@austinabell @ec2 I pushed some minor changes to deal with integer overflow in the same way the Go implementation does for which I had to drop down from ranges to runs because a trailing 0 run still shouldn't overflow 64 bits, which is why DecodedRanges was replaced by Runs. This PR should be good to go now.
I'll make a separate PR for removing the bitvec dependency.


Implement action for Force upgrade request answer

If api sends "Force upgrade" response ask user to forcefully upgrade. Should consult API team for specifics.

AFAIK it's already implemented in 02384ef0a054653009baaf63ba86f2ff0cfe5a23
Reopen if it something else is needed.


Interface to list their implementations

I noticed that in the templates for the docs, there is a section that should be listing the implementations of an interface. However, in code, no where are we setting such implementations. I've got something working for that but it was quickly hacked together so likely to contain bugs and the like. Before I get too far ahead though, I wanted to know why the templates have the section but code have no support for it. Was it just simply missed? Was it removed? Is someone currently working on it?

It would be truly awesome to have this functionality--for both interfaces and ideally typedefs too, with control over hiding certain ones...


Pacakge external references values should have dash character instead…

… of underscore to meet SPDX 2.2 specs
Fix #108

Why not add a     [EnumMember(Value = "string value")] to the enum itself, and use a string enum converter to serialize the data


animating an SVG transform attribute

Since CSS transforms on SVG items doesn't work in IE (and doesn't seem to work for  elements in Firefox, using the transform attribute is preferred.
Attempting to animate it with a value such as translate(0 -100) results in <rect> attribute transform: Unexpected end of attribute. Expected ')', "translate(0 "..

Hey good catch!
It's because the browser will get the initial value from the computed styles, and will return 'translate(0)' and the second value (y) will be undefined.
It's fixed in v3, you can use it now but there is no proper changelog yet.
Or define the initial value yourself, like this transform: ['translate(0 0), 'translate(0 -100)]

@juliangarnier awesome to see this has been caught already.
might have to try the 3.0 branch out, thanks :)


Build not working on windows for andriod

I'm unable to use this crate on windows when I build for andriod.
Here's the error
Compiling openssl-sys v0.9.66
   Compiling tokio v1.11.0
   Compiling url v2.2.2
   Compiling serde_json v1.0.68
error: failed to run custom build command for `openssl-sys v0.9.66`

Caused by:
  process didn't exit successfully: `C:\Users\taimoor\Desktop\Swift_final\downloader_lib\target\release\build\openssl-sys-2e2949ff20616409\build-script-main` (exit code: 101)
  --- stdout
  cargo:rustc-cfg=const_fn
  cargo:rerun-if-env-changed=AARCH64_LINUX_ANDROID_OPENSSL_LIB_DIR
  AARCH64_LINUX_ANDROID_OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
  OPENSSL_LIB_DIR unset
  cargo:rerun-if-env-changed=AARCH64_LINUX_ANDROID_OPENSSL_INCLUDE_DIR
  AARCH64_LINUX_ANDROID_OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
  OPENSSL_INCLUDE_DIR unset
  cargo:rerun-if-env-changed=AARCH64_LINUX_ANDROID_OPENSSL_DIR
  AARCH64_LINUX_ANDROID_OPENSSL_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_DIR
  OPENSSL_DIR unset
  cargo:rerun-if-env-changed=OPENSSL_NO_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64-linux-android
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS_aarch64_linux_android
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_ALLOW_CROSS
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64-linux-android
  cargo:rerun-if-env-changed=PKG_CONFIG_aarch64_linux_android
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64-linux-android
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_aarch64_linux_android
  cargo:rerun-if-env-changed=TARGET_PKG_CONFIG_SYSROOT_DIR
  cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR
  run pkg_config fail: "pkg-config has not been configured to support cross-compilation.\n\n                Install a sysroot for the target platform and configure it via\n                PKG_CONFIG_SYSROOT_DIR and PKG_CONFIG_PATH, or install a\n                cross-compiling wrapper for pkg-config and set it via\n                PKG_CONFIG environment variable."
  note: vcpkg did not find openssl: the vcpkg-rs Vcpkg build helper can only find libraries built for the MSVC ABI.

  --- stderr
  thread 'main' panicked at '

  Could not find directory of OpenSSL installation, and this `-sys` crate cannot
  proceed without this knowledge. If OpenSSL is installed and this crate had
  trouble finding it,  you can set the `OPENSSL_DIR` environment variable for the
  compilation process.

  Make sure you also have the development packages of openssl installed.
  For example, `libssl-dev` on Ubuntu or `openssl-devel` on Fedora.

  If you're in a situation where you think the directory *should* be found
  automatically, please open a bug at https://github.com/sfackler/rust-openssl
  and include information about your system as well as this message.

  $HOST = x86_64-pc-windows-msvc
  $TARGET = aarch64-linux-android
  openssl-sys = 0.9.66

  ', C:\Users\taimoor\.cargo\registry\src\github.com-1ecc6299db9ec823\openssl-sys-0.9.66\build\find_normal.rs:174:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: build failed

In my cargo.toml file
[dependencies]
reqwest = { version = "0.11", features = ["blocking", "json"] }
jni-sys = "*"
log = "*"
log-panics="*"
android_logger = "*"
serde_json = "*"
serde = { version = "*", features = ["derive"] }
derive-new = "*"

Looks like an issue finding openssl. You might need to look into use cargo-cross. Or it might be an environment variable you can set to help identify where it is. The message includes a link to a repository with more instructions and a way to file a bug. Since it's not something reqwest itself can do, I'm going to close this.


[travis] update gcc

I fixed the C++ setup failure in the test runner in 9bf7db189b4208698489ff5f4150bd3159186493. You can rebase your PR on latest master.

@scoder Ping.

Looks good, thanks!


deps: up goreleaser to v1.10.3

Details are here https://github.com/goreleaser/goreleaser/releases/tag/v1.10.3.

Up https://github.com/kamilsk/godownloader/blob/2524bba2ba03a6415649ab741bedb6f42f35a3c6/go.mod#L150


Add missing changelog for v2.1.1 of Self-Hosted

Description of the change
We created a hotfix release to fix a couple of specific issues, but forgot to add the information to the changelog.
Checklist
Please make sure that the proposed change checks all the boxes below before requesting a review:

[x] I have reviewed the guidelines for contributing to this repository.
[x] The preview looks fine.
[ ] The tests pass.
[x] The commit history is clean and meaningful.
[x] The pull request is opened against the main branch.
[x] The pull request is no longer marked as a draft.
[x] You agree to license your contribution under the MIT license to Spacelift (not required for Spacelift employees).
You have updated the navigation files correctly:

[x] No new pages have been added, or;
[ ] Only nav.yaml has been updated because the changes only apply to SaaS, or;
[ ] Only nav.self-hosted.yaml has been updated because the changes only apply to Self-Hosted, or;
[ ] Both nav.yaml and nav.self-hosted.yaml have been updated.

If the proposed change is ready to be merged, please request a review from @spacelift-io/solutions-engineering. Someone will review and merge the pull request.
Spacelift employees should request reviews from the relevant engineers and are allowed to merge pull requests after they got at least one approval.
Thank you for your contribution! 🙇

The QA check is failing because it's getting a 403 from https://code.visualstudio.com/docs/editor/tasks. I'm just going to merge for now in case it's just a transient issue (the page definitely exists), and if it continues to fail we can do something, for example ignore that link.


Questions on online quantization

Nice paper and repo!
I'm trying to get a clear understanding of QuaRot to see if we can integrate it into LMDeploy. I have some questions on the online quantization part

It seems that all hadamards for online quantization are not randomized. If I'm understanding it right, the randomness brought by the global randomized hadamard transformation Q has no effective on the FP16 components inside a FFN/attention block. Is the quality of online quantization not impacted by the randomness or we can get more performance by using full RHT here?

Can we omit the partial hadamard before o_proj by applying only head-wise hadamard rotation to values like how queries and keys are processed? I'm confused on why it must be done to ensure correctness.

Is the second d_h in the first line a typo?

Thanks very much!

@lzhangzz
Thank you so much for your questions.

It seems that all hadamards for online quantization are not randomized. If I'm understanding it right, the randomness brought by the global randomized hadamard transformation Q has no effective on the FP16 components inside a FFN/attention block. Is the quality of online quantization not impacted by the randomness or we can get more performance by using full RHT here?

We have done a few experiments to understand this. It seems that you can get better accuracy by using RHT. However, we have a fast CUDA kernel only for Hadamard transformations, and using RHT results in slower transformations. So we used RHT when we want to fuse the transformations into the weights (so this will have no overhead during the inference) and deterministic hadamards for our online transformations.

Can we omit the partial hadamard before o_proj by applying only head-wise hadamard rotation like how queries and keys are processed? I'm confused on why it must be done to ensure correctness.

We fuse the inverse of the (full) Hadamard in o_proj weights. This means that the input of o_proj should be transformed using a full Hadamard transformation. To this end, we fuse per-head transformations into the v_proj weights so we need to apply outer-head transformation online to get full Hadamard transformation.

Is the second d_h in the first line a typo?

No. This is right. I just explained it in the previous question.
Please let me know if you have any other question :)

@lzhangzz
Thanks

So have you tried to use only the head-wise transformation for the values and see how it impact performance?

Actually, this is a very good question. We started with this but the accuracy of per-head rotation was bad! However, another option is to rotate per-head and then quantize the inputs using group-wise quantization (instead of row-wise in the current setting) with group-wise=head_dim. This can solve the issue (we have done some experiments and I can verify it) in the cost of doing group-wise quantization in o_proj.
In conclusion, it is important to apply quantization on the same granularity as Hadamard. If you only apply Hadamards on each head separately, the scales between different heads will be different and quantizing across the whole heads leads to poor accuracy.

However, another option is to rotate per-head and then quantize the inputs using group-wise quantization (instead of row-wise in the current setting) with group-wise=head_dim.

This is great. It's useful in tensor parallel mode where you don't have access to all channels without communicating with other ranks.


turn scene crash.

Godot version:
3.1.1
OS/device including version:
mac 10.14.4
Issue description:
turn another scene crash.
Steps to reproduce:

reactive from background.
click the deactive scene.
show a scene loading panel.
crash when two seconds. (immediately disapear. not stack at there.)

turn scene crash.log

This sounds similar to #28228, but has different log.

@KoBeWi maybe cause by memory lack.

@zszen Can you (or anyone else) still reproduce this bug in Godot 3.2.2 or any later release?
If yes, please ensure that an up-to-date Minimal Reproduction Project (MRP) is included in this report (a MRP is a zipped Godot project with the minimal elements necessary to reliably trigger the bug). You can upload ZIP files in an issue comment with a drag and drop.

Closing due to lack of update. Please comment if you can still reproduce this issue in the latest stable version of Godot.


interop_test changed to use gpr_ versions to prepare for windows port

these changes were done by copying gpr_ bits from fling_test.c to replace posix things.  It compiles fine on ubuntu but the test's output now has:
E0723 09:01:12.432994546   27586 subprocess_posix.c:100]     waitpid failed: No child processes
this is the same as the output of fling_test, it happens when gpr_subprocess_destroy is run after it's already been joined.  It doesn't cause a test failure (status = 0).  I dunno.

Can one of the admins verify this patch?

This is ok to test.

this PR is now complete.  it's 3 changes:

change interop_test and interop_client/ interop_server to use the portable gpr_ versions of everything.  This can be verified independent of the windows changes to run the same on unix hosts as before.  These changes conflict with at least one other interop PR, ping me to update things as needed
add subprocess support for windows.  this went OK except there isn't an easy way to send ctrl-c to a subprocess, so ctrl-break is sent instead.  this causes a failed return code, so it's ignored in this case.  return codes work otherwise.  this will prevent detecting improper shutdown of servers, for example
change pick_unused_port() to run grpc_init() (windows version only).  WSAStartup() is required before doing anything with a socket, so it needs to be run.  I'm not sure what to do about shutdown (where to put it) or if this should be grpc_iomgr_platform_init() instead.  this fixes the problem in #2294

This conflicts with #2603 which is waiting on a merge.  I'm going on vacation in a couple days and I probably won't be able to fix it up till early September, feel free to pluck changes out or use for inspiration if this needs to be bypassed.  This set of changes enables a few c++ tests besides just interop to run on windows, so it'll be important once windows C++ CI is set up.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Closing stale PR.

I'm... going to steal portions of that :)


Submitting Proposal UI

Going with this mockup more or less, but not sure whether it makes sense for beginners users with regard to things like prompting the user to paste in raw bytes for an extrinsic. CC: @amaurymartiny @Tbaut

Agreed, the word extrinsic itself is scary. I think creating proposals is for advanced users, at least for now... until we figure out what users would like to propose regularly and that wouldn't require good knowledge of substrate/polkadot to be proposed.
A couple comments as they came to my mind:

I'm not sure if you should mix the chains (visible on the left). To me (I might very well be wrong) users evolve in the environment of a parachain, or the relay chain, but not in all at the same time. I'd very well see a drop-down a la "Network selection" from Metamask.
Proposals can be seconded but not voted on, only referenda can be voted on.
Beside voting on referenda, users will eventually second or look at who seconded what proposal (many users might second proposals). I guess it can be hard to represent it like this on a single line, this might require a popup or something similar.
Not sure if it's what you meant to do: A nice explanation for what an extrinsic does is quite tricky I guess as things might change. I guess we could work on the metadata to have better wording of extrinsic's description, but reworking and mapping user-friendly description seems like a tedious work.
I guess you're a mac user for so long that you put close button on the left side!

Other than that it's promising!


[Feature]: If nix isn't installed, devbox should run the multiuser determinate systems installer instead of the single user installer

Is your feature request related to a problem you're trying to solve? Please describe.
It is just a better installer
Describe the solution you'd like
It should run the multiuser determinate systems installer instead
Describe alternatives you've considered
There really aren't alternatives for this
Additional context
It is a better installer than the single user official nix installer

I think this is something we definitely want to do. It would also unblock #1311 and fix issues like #1263.

I'm somewhat hesitant to do this soon: we also want to enable a way for users to update their nix, and this would add another scenario to support for that.

the biggest problem with single user nix is that no other user can use nix on the system


Non-HASSIO usage instructions / release artifact

Select Add-On (place a lowercase x for the relevant add-on)

[X] Xiaomi Mi Scale 2

Is your feature request related to a problem? Please describe.
I'm using python-based HA. I'm not sure how to use your addon - i've extracted repo into custom_components and changed configuration - but HA sensors are not updated and there is nothing in MQTT.
Describe the solution you'd like
Please do actions release or graft some instruction on how to use with HA.
Describe alternatives you've considered
None at the moment.
Additional context
Add any other context or screenshots about the feature request here.

Also HA version 0.118.4,
I've updated MAC, and all config params.
Other modules from custom_components are working.

This repo is only for the home assistant version, aka hass.io, not for the core version.
Use this version instead
https://github.com/lolouk44/xiaomi_mi_scale


Beautified the main readme with maintainers details and labels

fixes #65
screenshots

@Arindam200 please review

Thanks @akshitagupta15june  for your great work!


[bug]: v5.2.0 - gallery stops populating with new images.

Is there an existing issue for this problem?

[X] I have searched the existing issues

Operating system
Linux
GPU vendor
Nvidia (CUDA)
GPU model
3090
GPU VRAM
24Gb
Version number
5.2.0
Browser
131.0.3 (64-bit)
Python dependencies
{
"accelerate": "0.30.1",
"compel": "2.0.2",
"cuda": "12.4",
"diffusers": "0.27.2",
"numpy": "1.26.4",
"opencv": "<IP_ADDRESS>",
"onnx": "1.16.1",
"pillow": "11.0.0",
"python": "3.10.15",
"torch": "2.4.1+cu124",
"torchvision": "0.19.1+cu124",
"transformers": "4.41.1",
"xformers": null
}
Just noticed xformers is not installed that may explain a few other issues perhaps?
What happened
The gallery has stopped populating with new images. Though the images and thumbnails are still be generated correctly and can be browsed from the output directory.
Even after shutting down and restarting the application this still happens for new images.
I set the log to debug but nothing shows.
What you expected to happen
The gallery should be populated.
There should be an error message if it cannot be for any reason.
How to reproduce the problem
Generated many images over many cycles without deleting any with a queue of different models.
There were some errors. Workflows do not work for me. I also have invokeai-web on a loop in a script as it sometimes dies due to lack of main memory (particularly if something else running uses main memory).
Additional context
I am running on Ubuntu 24.04 under WSL on windows 11.  (my linux box does not have a good enough GPU)
I suspect if I clear out some images it will come back but I can leave it in its current broken state for a while in case there is something to look for that explains what's going wrong.
Discord username
No response

Do you have this set to Send to Gallery?

If it is instead set to Send to Canvas, your generations will be on the canvas instead of the gallery until you accept them.

Yes. Definitely set to send to gallery. I ended up resetting the web UI and clearing intermediates and it works now.
However, the images I generated before doing that are still missing from the gallery (but present in the output directory).

Ok, glad it's working. You could technically drag those images back in but there's no automated way to restore them at this time.
Hmm, curious why it happened. I haven't run into this before. One thing to note - when you click Invoke, the queued generations all have the Send to... setting baked in. So, changing it after queuing generations, will not re-route the images.


Feature: Tab to select line and move down

The Tab behavior is already defined in multi_select.rs#L249, but the change would likely be in match term.read_key() redefining the behavior of Key::Tab and Key::BackTab to select and move to the next line or back and unselect respectively e.g.
match term.read_key()? {
    Key::Tab => {
        checked[sel] = !checked[sel];
        if sel == !0 {
            sel = 0;
        } else {
            sel = (sel as u64 + 1).rem(self.items.len() as u64) as usize;
        }
    }
    Key::BackTab => {
        if sel == !0 {
            sel = self.items.len() - 1;
        } else {
            sel = ((sel as i64 - 1 + self.items.len() as i64)
                % (self.items.len() as i64)) as usize;
        }
        checked[sel] = !checked[sel];
    }
    Key::ArrowDown | Key::Char('j') => {
        if sel == !0 {
            sel = 0;
        } else {
            sel = (sel as u64 + 1).rem(self.items.len() as u64) as usize;
        }
    }
    Key::ArrowUp | Key::Char('k') => {
        if sel == !0 {
            sel = self.items.len() - 1;
        } else {
            sel = ((sel as i64 - 1 + self.items.len() as i64)
                % (self.items.len() as i64)) as usize;
        }
    }
...
}

Is the project open to changing this behavior?

That's not how the tab shortcut is generally used AFAIK.


Migrate from XPBD to Avian if Avian & Oxidized Navigation is ready .

Greetings, as XPBD is being discontinued, I've been migrating my new app based on this template to Avian and This & Oxidized Navigation are the last dependencies I have that don't have an Avian based version. Thanks for putting in the effort to migrate when you do! :D

Definitely will. I'm waiting for the Blenvy release at the moment to start migration :)

Closing this as a subset of https://github.com/janhohenheim/foxtrot/issues/327


Add Ben And Al as approvers for Notifications

@a-b and @Benjamintf1 - I love y'all working on notifications more over time, but we have to say several demonstrated contributions to be considered for approver status. I see Duane has done enough to qualify (in my opinion) and Ryker as started some contributions. Please send PRs for now and I'll approve them (or add Duane as well if he'd like). Then we can revisit this one in a month or so.

@dsboulder I should mention that I've been a contributor to notifications in the past, should show up in the git history.

Some images(idk how to better demonstrate) to demonstrate contributions to notifications and notifications-release

ping @dsboulder ^

For the records the contributions done by @Benjamintf1 to the Notifications are (generated by using the contributions-for-user.sh script)
App Runtime Interfaces: Notifications Contributions
PRs Commented on/Reviewed:
Issues that may be relevant:

2023-08-01T20:37:14Z: Upgrade jwt libraries as much as possible

Code contributions:

2023-07-31T21:51:37Z: upgrade warrent
2023-07-31T22:50:19Z: work in progress
2023-08-01T17:07:44Z: work in progress
2023-08-01T17:46:46Z: fix hsa test
2023-08-01T18:45:54Z: switch main module over to golang-jwt, move old dependency to old version
2023-08-01T20:18:24Z: update jwt to v4
2023-08-01T20:18:48Z: update jwt to v4
2023-08-01T20:25:13Z: upgrade to v5
2023-08-01T20:34:36Z: upgrade depedency to latest version for old jwt repository

@a-b is this promotion still relevant because it is open for quite long time and there is no activity on it?

Hi @beyhan, yes, this is still relevant.

Sorry for the delay, I approve this PR. @Gerg can you also give us your official take?


sorted_redaction sorts array of array properly?

What happened?
I expected sorted_redaction to properly sort inner arrays but it does not.
Reproduction steps
I have a json which is KeyName: [["one", "two"]].
I was expecting that "KeyName[]" => insta::sorted_redaction() would sort the inner arrays as well. It doesn't - I still get failing tests.
Insta Version
1.40
rustc Version
1.81
What did you expect?
It should have sorted the inner arrays.

Ah my mistake - I didn't think about what it's actually needing to do. It has to rewrite the existing snapshot with the sorted order. After regenerating the snapshots it worked as expected.


【debug】New/tmp

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation
Debug
Modification
Please briefly describe what modification is made in this PR.
BC-breaking (Optional)
Does the modification introduce changes that break the backward compatibility of the downstream repositories?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here and update the documentation.
Checklist
Before PR:

[ ] Pre-commit or other linting tools are used to fix the potential lint issues.
[ ] Bug fixes are fully covered by unit tests, the case that causes the bug should be added in the unit tests.
[ ] The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
[ ] The documentation has been modified accordingly, like docstring or example tutorials.

After PR:

[ ] If the modification has potential influence on downstream or other related projects, this PR should be tested with those projects.
[ ] CLA has been signed and all committers have signed the CLA in this PR.

end debug


Design WAS and VS Graph(s)

💡 Summary
We need visually appealing graphics to represent the Vulnerability Scan (VS) components on our dashboard. These graphics will enhance the user experience and provide a clear visual representation of these crucial elements.
Motivation and context
A required report metric.
Implementation notes
VS Graphics Design:

Create a graph(s) or visual that symbolizes each service.
Ensure the design aligns with our dashboard’s overall aesthetics.
Maintain consistency with other dashboard graphics.

Acceptance criteria
How do we know when this work is done?

[x] The graphics are visually appealing and easily distinguishable.
[x] The designs align with our dashboard’s aesthetics.

It was determined the first UI graphic update will be a VS Vulnerability Scanning high level metrics.


Script to create Pelorus Operator should properly tag IS, and images for exporters

Current way of tagging Pelorus Operator and it's exporter images in our scripts is wrong.
A bit of background to capture what's where and how the scripts should be working:

For each exporter deployment or exporter build (referenced by the app_name in the instance creation) we do create corresponding app_name ImageStream in the Pelorus namespace, so for the:

exporters:
  instances:
  - app_name: deploytime-exporter
    exporter_type: deploytime
    image_tag: stable

  - app_name: deploytime-notag
    exporter_type: deploytime

  - app_name: deploytime-latest
    exporter_type: deploytime
    image_tag: latest

  - app_name: deploytime-master
    exporter_type: deploytime
    source_ref: master
    source_url: https://github.com/konveyor/pelorus.git

  - app_name: deploytime-version
    exporter_type: deploytime
    image_name: quay.io/pelorus/pelorus-deploytime-exporter
    image_tag: v2.6.0

We will get the following image streams:
$ oc get is -n pelorus
NAME                  IMAGE REPOSITORY                                                               TAGS     UPDATED
deploytime-exporter   image-registry.openshift-image-registry.svc:5000/pelorus/deploytime-exporter   stable   10 seconds ago
deploytime-latest     image-registry.openshift-image-registry.svc:5000/pelorus/deploytime-latest     latest   10 seconds ago
deploytime-master     image-registry.openshift-image-registry.svc:5000/pelorus/deploytime-master
deploytime-notag      image-registry.openshift-image-registry.svc:5000/pelorus/deploytime-notag      stable   10 seconds ago
deploytime-version    image-registry.openshift-image-registry.svc:5000/pelorus/deploytime-version    v2.6.0

We can see that two of the ImageStreams do not have tags:
deploytime-master
deploytime-version

The first one is because the OCP is building our image from the source, and basically the source build did not finish yet. Once it finishes the deploytime-master will get tag latest, but the deploytime-version will not get any tag because we specified to use v2.6.0 which is missing from our quay.io/pelorus/pelorus-deploytime-exporter image.
Those ImageStreams are created using helm templates (charts/subcharts/exporters/templates):

for the from the source deployment type: _imagestream.yaml
for from the image deployment type: imagestream_from_image.yaml

Those ImageStreams are local to the cluster and the tags in ImageStream are also local to the cluster, so we can have stable label referencing any quay.io tag we want.
The ImageStream part from our templates responsible for setting local tag is quite confusing and here is a stripped down version of the imagestream_from_image.yaml to explain what is what.

On line number 6 we define ImageStream, which matches our app_name, so the name applies to the ImageStream.
On line number 13 we point to the quay.io image with the tag of that exporter image, so the name is defacto an URI of the podmnan exporter image.
On line number 14 we define an ImageStream TAG for that has nothing to do with the quay.io tags nor the image names. It is just  the TAG within the ImageStream local to the OCP cluster. In our case we have only one tag per ImageStream corresponding to the deployed exporter. The line number 14 can be anything, but must be a valid tag. This later by other charts is used to point to the local image registry as the: app_name:TAG, where app_name is the one from line 6 and TAG is from the line 14. See _deploymentconfig.yaml example below.

---
1  apiVersion: image.openshift.io/v1
2  kind: ImageStream
3  metadata:
4      labels:
5          app.kubernetes.io/name: {{ .app_name }}
6      name: {{ .app_name }}
7  spec:
8      lookupPolicy:
9          local: true
10    tags:
11    - from:
12        kind: DockerImage
13        name: quay.io/pelorus/pelorus-{{ .exporter_type }}-exporter:{{ .image_tag | default "v2.0.7" }}
14    name: {{ .image_tag | default "stable" }}
15    referencePolicy:
16        type: Local
{{- end }}

The local ImageStream is being used in our _deploymentconfig.yaml and the name must match the created ImageStream name. Note that for the deployment from the source defined by the source_ref or/and source_url it's :latest.
  triggers:
  - type: ConfigChange
  - imageChangeParams:
      automatic: true
      containerNames:
      - {{ .app_name }}
      from:
        kind: ImageStreamTag
        {{- if or .source_ref .source_url }}
        name: {{ .app_name }}:latest
        {{- else }}
        # default is an internal registry tag and must match the default from
        # _imagestream_from_image.yaml
        name: {{ .app_name }}:{{ .image_tag | default "stable" }}
        {{- end }}
    type: ImageChange

So our script to create operator and modify those helm chart templates is not right atm

This issue is not valid anymore. There was change which really resolved the issue with the is tags:
https://github.com/dora-metrics/pelorus/pull/845


New functions in Tc2_System

Three new functions I discovered while exploring Infosys

Hi @jacek-domanski. Thanks for the PR! Nice find.


Can't execute ConstraintSuggestionRunner: Constructor com.amazon.deequ.suggestions.rules.CategoricalRangeRule([]) does not exist

I'm trying to run the ConstraintSuggestionRunner with the latest version of pyDeequ that supports Spark 3.1. I encountered the following error when I was running this code
from pydeequ.suggestions import *

suggestionResult = ConstraintSuggestionRunner(spark) \
             .onData(df) \
             .addConstraintRule(DEFAULT()) \
             .run()

print(json.dumps(suggestionResult, indent=2))

---------------------------------------------------------------------------
Py4JError                                 Traceback (most recent call last)
<command-3959492557277844> in <module>
      1 from pydeequ.suggestions import *
      2
----> 3 suggestionResult = ConstraintSuggestionRunner(spark) \
      4              .onData(df) \
      5              .addConstraintRule(DEFAULT()) \

/local_disk0/.ephemeral_nfs/envs/pythonEnv-5e8d3820-b76d-4b1b-ab52-2e507e080d3f/lib/python3.8/site-packages/pydeequ/suggestions.py in addConstraintRule(self, constraintRule)
     64             for rule in constraintRule_jvm:
     65                 rule._set_jvm(self._jvm)
---> 66                 rule_jvm = rule.rule_jvm
     67                 self._ConstraintSuggestionRunBuilder.addConstraintRule(rule_jvm)
     68

/local_disk0/.ephemeral_nfs/envs/pythonEnv-5e8d3820-b76d-4b1b-ab52-2e507e080d3f/lib/python3.8/site-packages/pydeequ/suggestions.py in rule_jvm(self)
    184     @property
    185     def rule_jvm(self):
--> 186         return self._deequSuggestions.rules.CategoricalRangeRule()
    187
    188

/databricks/spark/python/lib/py4j-0.10.9-src.zip/py4j/java_gateway.py in __call__(self, *args)
   1566
   1567         answer = self._gateway_client.send_command(command)
-> 1568         return_value = get_return_value(
   1569             answer, self._gateway_client, None, self._fqn)
   1570

/databricks/spark/python/pyspark/sql/utils.py in deco(*a, **kw)
    108     def deco(*a, **kw):
    109         try:
--> 110             return f(*a, **kw)
    111         except py4j.protocol.Py4JJavaError as e:
    112             converted = convert_exception(e.java_exception)

/databricks/spark/python/lib/py4j-0.10.9-src.zip/py4j/protocol.py in get_return_value(answer, gateway_client, target_id, name)
    328                     format(target_id, ".", name), value)
    329             else:
--> 330                 raise Py4JError(
    331                     "An error occurred while calling {0}{1}{2}. Trace:\n{3}\n".
    332                     format(target_id, ".", name, value))

Py4JError: An error occurred while calling None.com.amazon.deequ.suggestions.rules.CategoricalRangeRule. Trace:
py4j.Py4JException: Constructor com.amazon.deequ.suggestions.rules.CategoricalRangeRule([]) does not exist
	at py4j.reflection.ReflectionEngine.getConstructor(ReflectionEngine.java:202)
	at py4j.reflection.ReflectionEngine.getConstructor(ReflectionEngine.java:219)
	at py4j.Gateway.invoke(Gateway.java:248)
	at py4j.commands.ConstructorCommand.invokeConstructor(ConstructorCommand.java:80)
	at py4j.commands.ConstructorCommand.execute(ConstructorCommand.java:69)
	at py4j.GatewayConnection.run(GatewayConnection.java:251)
	at java.lang.Thread.run(Thread.java:748)

Additional information:

I'm working with Spark 3.1, to cooperate with the version, I used the pyDeequ package as instructed here. Everything else is exactly the same as written in the tutorial

from pyspark.sql import SparkSession, Row, DataFrame
import json
import pandas as pd
import sagemaker_pyspark

import pydeequ

classpath = ":".join(sagemaker_pyspark.classpath_jars())

spark = (SparkSession
    .builder
    .config("spark.driver.extraClassPath", classpath)
    .config("spark.jars.packages", 'deequ-2.0.0-spark-3.1.jar') # this is where i changed
    .config("spark.jars.excludes", pydeequ.f2j_maven_coord)
    .getOrCreate())

I tried other functions like VerificationSuite() and AnalysisRunner(), they both work fine.

Is it bc of the version I'm running that haven't supported this specific functionality in Spark 3.1 yet? I think I can avoid this
by downgrading Spark version but I would not do that until no other solutions. Any insights would be really appreciated!

I am also seeing this issue, using Spark 3.1, pydeequ version 1.0.1

Attempting to bump this as I'm seeing the same error when trying to use pydeequ with Spark 3.1.x.

Hi everyone. I have the same error and it seems that something is wrong with the Categorical Suggestion Rules functions. If I run
from pydeequ.suggestions import *

suggestionResult = (
    ConstraintSuggestionRunner(spark)
    .onData(df)
    .addConstraintRule(CompleteIfCompleteRule())
    .addConstraintRule(NonNegativeNumbersRule())
    .addConstraintRule(RetainCompletenessRule())
    .addConstraintRule(RetainTypeRule())
    .addConstraintRule(UniqueIfApproximatelyUniqueRule())
    .run()
)

all is well. However if I run
suggestionResult = (
    ConstraintSuggestionRunner(spark)
    .onData(df)
    .addConstraintRule(CategoricalRangeRule())
    .run()
)

or
suggestionResult = (
    ConstraintSuggestionRunner(spark)
    .onData(df)
    .addConstraintRule(FractionalCategoricalRangeRule())
    .run()
)

I get the same error described by @lzhong1, each one for the respective function ran. Do you guys have any intention on working on this?
I am running the tests locally on a Mac M1, Pyspark 3.1.2, Scala 2.12.10. My spark-submit is like this:
spark-submit --packages com.amazon.deequ:deequ:2.0.0-spark-3.1 --exclude-packages net.sourceforge.f2j:arpack_combined_all pydeequ_test.py

Many thanks!

+1

The problem comes from here:
https://github.com/awslabs/deequ/blob/master/src/main/scala/com/amazon/deequ/suggestions/rules/CategoricalRangeRule.scala#L29
This is CategoricalRangeRule and FractionalCategoricalRangeRule are the only 2 rules that accept arguments to the constructor.
And according to this:
https://github.com/awslabs/python-deequ/blob/master/pydeequ/suggestions.py#L169
DEFAULT function creates objects without passing arguments. I think, if one correctly calls them separately it will work.
However, this should be somehow fixed, I agree


Time Series Bars Visualization not decending when set

Bar chart timeseries visalization order descending control doesn't work
Expected results
All bars in the chart should be sorted descending with the control set
Actual results
The bar orderings don't change at all
Screenshots

How to reproduce the bug

Go to an explore view
Click on 'visualization type' and pick timeseries bar chart
Select sort descending on the controls to the left.
See error

Environment
(please complete the following information):

superset version: superset version
python version: python --version
node.js version: node -v
npm version: npm -v

Checklist
Make sure these boxes are checked before submitting your issue - thank you!

[ ] I have checked the superset logs for python stacktraces and included it here as text if there are any.
[ ] I have reproduced the issue with at least the latest released version of superset.
[ ] I have checked the issue tracker for the same issue and I haven't found one similar.

Additional context
Add any other context about the problem here.

@hughhhh Can you answer the version questions?


Fix destructor order for _MessageReader

_PackedMessageReaderBytes must delete self.thisptr before self.stream because the destructor for the former references the latter. This fixes a crash that seems to occasionally be tripped at GC time (see https://github.com/jparyani/pycapnp/issues/39).

Thanks for fixing this! Sorry I didn't have any time this weekend to look into it myself, but you came up with a good fix. I'll push an updated build to pypi in a bit.

No prob, thanks for the awesome library!


Task should be lease with only 1 minute lease.

The task lease the should be updated, before the lease expires if the tasks is still working on, it should re updated up to a given max time.

This is specially important, because when some tasks fail, it takes too long for them to get rerun.


Don't launch Nudge if apps listed in acceptableApplicationBundleIDs are the frontmostApplication

This feature as implemented in https://github.com/macadmins/nudge/pull/208 currently only works on subsequent launches and not if Nudge had been dismissed in the past.
It would be ideal if the admin could define a preference so that if Nudge attempted to launch and the apps defined in acceptableApplicationBundleIDs were foremost (On a video call, presenting a Keynote, etc), Nudge would log this and not launch.
In order to not impede the security of your fleet, it would make sense to only apply this when a device has not yet passed the requiredInstallationDate.
I do not know what the correct behaviour should be if a user has exceeded their deferrals, but it is still before the install date. Should Nudge respect the acceptableApplicationBundleIDs dict because it's before the required install date, or launch because they have exceeded their deferral limit?

One thing I said on Slack but will say here. With Nudge v1.1, it is very likely that the amount of nudge launches/re-activations will significantly decrease per nudge event compared to v1.0.
If say you have a required install for 10/01/2021 and the nudge event starts 09/01/2021, the user could actually defer until 09/28/2021. At this point, the user only has 3 days remaining to install the update and it's highly likely you want as many launches/activations as possible at that point.
I can understand wanting this behavior in v1.0, but I think you should deploy v1.1 and see how things are. I'm pretty confident you will close this ticket once you see less of an occurrence it actually is.

@smithjw : this is an old issue.  Is it still a problem with any Nudge v1.1 branch, or is it working to your satisfaction and can be closed?


Issue reading c180 GEOS-IT mass flux in c180 GCHP simulation

I am using MAPL 2.26.0 to run GCHP at C180 with GEOS-IT meteorology. Since what I am reading and running are the same resolution, I supposed there should not be a regridding issue. Surprisingly, I got the error message below:
pe=00000 FAIL at line=00147    NewRegridderManager.F90                  <no such property>
pe=00000 FAIL at line=00092    NewRegridderManager.F90                  <status=1>
pe=00000 FAIL at line=01006    GriddedIO.F90                            <status=1>
pe=00000 FAIL at line=04705    ExtDataGridCompMod.F90                   <status=1>
pe=00000 FAIL at line=01490    ExtDataGridCompMod.F90                   <status=1>

I looked through the issues and found #2118 and #1124. From my understanding, the HFLUX essentially requires the resolution divisible by the Nx and Ny after decomposition.
In my case, however:

Simulation resolution is the same as the raw file, so regridding itself is unnecessary.
Even if we imagine a case where C180 is regridded to C180, I tested with both 49*24 cores (Nx=14, Ny=14*6, 180/14 is not integer) and 36*24 cores (Nx=12, Ny=12*6, 180/12=15). They both failed with the same error mentioned above.
Interestingly, if I follow the rules and actually do the regridding: read C180 but run at C90 with 25*24 cores (Nx=10, Ny=10, 90/10=9), it works!

Related entries in my ExtData.rc are:
MFXC;MFYC Pa_m+2_s-1 N H F0;003000 none  0.6666666 MFXC;MFYC ./MetDir/%y4/%m2/%d2/GEOS.it.asm.ctm_tavg_1hr_glo_C180x180x6_v72.GEOS5294.%y4-%m2-%d2T%h2%n2.V01.nc4 1995-01-01T00:30:00P01:00
CXC;CYC   1          N H F0;003000 none  none      CX;CY     ./MetDir/%y4/%m2/%d2/GEOS.it.asm.ctm_tavg_1hr_glo_C180x180x6_v72.GEOS5294.%y4-%m2-%d2T%h2%n2.V01.nc4 1995-01-01T00:30:00P01:00

For a workaround, I replace H with N and manually bypass the regridding. It works as well.

The compiler is intel with MPT mpi if that matters.

Well, since this is ExtData related I'm adding @bena-nasa.
But I'll also mention @tclune and @atrayano as, well, they know this stuff in a way too.
Note that MAPL 2.26 is a bit ago so perhaps this has been fixed? Though if so, might have been in ExtData2, not 1.

It suddenly came to me that @lizziel did several Transport-Tracer simulations with raw c180 GEOS-IT at C180 resolution on Discover. Did you encounter this problem?

Given that things seemed to work for @lizziel my primary suspicion is that the code is failing to detect that the two grids are in fact identical.  But even then, I would have expected the code to work, just wasting resources computing what amounts to an identity transform.

@yuanjianz  Probably not important, but I am confused by the fact that the linked version of MAPL above does not actually produce the error message given in the traceback.  ("no such property" does not occur in NewRegridderManager.F90)
It will be important for us to confirm the precise version of MAPL to track this down.

I am looking into this now, first trying to figure out why a subroutine in GriddedIO.F90 is returning false when checking if file grid and run grid are the same. That should be true for the GEOS-IT input file if running at C180.
Regarding NX and NY, I did C180 runs with NX=6, NY=30. I did not play with other combinations. Could it be that file resolution divided by NX must be even?

@tclune I double checked, and I confirmed the MAPL version and the link was correct.
I did some extra tests, and it seems to be related to the total cores I apply. My previous failed tests were 1176 and 876 cores in total. However, my recent test with 600 cores in total at C180 succeed.
@lizziel 's suggestion might be correct. In both 1176 (14x14x6) and 876 (12x12x6) tests, 180 divided by Nx is non-even number, while the 600(10x10x6, 180/10=18) test turns out successful.

Regarding the unequal grids, here is the line that results in false: https://github.com/GEOS-ESM/MAPL/blob/b76ba1a1f2e0e1ed01bcb13cd3af3511760dc815/griddedio/GriddedIO.F90#L1099
I printed out the two grids and get this:
ewl: filegrid not equal to output_grid: ./MetDir/2019/01/01/GEOS.it.asm.asm_tavg_3hr_glo
_C180x180x6_v72.GEOS5294.2019-01-01T0130.V01.nc4
filegrid:
 Object has been CREATED
 Base name    = UNKNOWN
 Status: Base = Ready,  object = Ready
 Proxy        = no
 Base ID = 2530, vmID:
--- ESMCI::VMId::print() start ---
  vmKeyWidth = 12
  vmKey=0xFFFFFFFFFFFFFFFFFFFFFFC0  localID = 1
--- ESMCI::VMId::print() end ---
 Root Info (Attributes):
{
  "ESMF": {
    "General": {
      "GRID_LM": 72,
      "GridType": "Cubed-Sphere",
      "MAPL_grid_factory_id": 2,
      "NEW_CUBE": 1
    }
  }

output_grid:
} Object has been CREATED
 Base name    = PE180x1080-CF
 Status: Base = Ready,  object = Ready
 Proxy        = no
 Base ID = 20, vmID:
--- ESMCI::VMId::print() start ---
  vmKeyWidth = 12
  vmKey=0xFFFFFFFFFFFFFFFFFFFFFFC0  localID = 1
--- ESMCI::VMId::print() end ---
 Root Info (Attributes):
{
  "ESMF": {
    "General": {
      "GRID_LM": 72,
      "GridType": "Cubed-Sphere",
      "MAPL_grid_factory_id": 1,
      "NEW_CUBE": 1
    }
  }

This is MAPL 2.26. "no such property" is in MAPL_ErrorHandling.F90.

I was able to run GCHP at C180 using C180 mass fluxes with the following combos:
96 cores, NX=4 (180/4=45 which disproves my even number theory)
150 cores, NX=5
216 cores, NX=6
Like @yuanjianz, 864 cores with NX=12 failed for me.

Interesting - will have to investigate further.  Hopefully we can reproduce on our end.

@lizziel so sounds like you ran this on Discover? Maybe? If so, where are these GEOS-IT files on Discover or your input file with the path?

@bena-nasa since GriddedIO.F90 failed to detect the two grids are identical, do you see any potential errors that could be introduced by setting regridding method to N to bypass the regridding? (N seems to be bilinear regridding)

@tclune @lizziel
I think I see what the problem is.
Now when the file is read, it tries to made a grid from that file so know, do I need to regrid. Well, it has to just choose an nx and ny and it turns out it chooses a 9x16 layout on each face. We may have a different heuristic that tries to make a more square decomposition (which would be a perfect 12x12) we could use, but it would still rely on coincidence since the user can set whatever decomposition they want.
So the two grids are not the same grid and it tries to find a regridder which in this case is the flux regridder. And there's no flux regridding that can do what is essentially a redistribution of the data so it fails.
If you set the regridding to any other regrid method goes through ESMF it will just work since ESMF can always regrid between these two grids which are really just the same grid, different layouts, so yes, you would get past this error and the regridder it spawned would be the identity for all practical purposes.
The only solution to this is that we essentially do not allow the user to choose the decomposition. It ALWAYS chooses a grid decomposition based on the core count and we make sure we are always using the same algorithm.
If the user has freedom, there's no solution since they can always choose something other than what an algorithm would choose.

Thanks @bena-nasa. For nearly all GCHP users the domain decomposition is chosen automatically anyway as a pre-run step I added to the run script. So making this built-in would not be a problem. However, it would be nice to have an override option for testing (e.g. to run at two different domain decomps and check bit-for-bit reproducibility) as well as for domain decomposition research.

Tagging @sdeastham


feat: Add react-native suport

Add react-native support for TextInput components

Changes proposed
So, I was reading #42 and think that I could make an initial code for it. Here I am.
To make Unform work in React Native, I added it in devDependencies, and made an example folder to RN too, linking dependencies that are already in use on the main package.json. The example is working, you can check it out.
To use the native part, we can import with import {} from '@rocketseat/unform/native'.
I had to think a little on how to work with the submit of the form. Ended in a hook: useSubmit. Like useField, we need to wrap it in a component, like a SubmitButton (maybe we can provide a standard one too). So, it will return a function (handleSubmit) that we can call by passing to the Touchable onPress. This function will call the original handleSubmit, that catches the onSubmit passed to the Form component, like in the ReactJS version.
The Form component turns a RN View without HTML-like props. The same to Input, but with RN TextInput. In Input, the value is provided by the prop _lastNativeProps from the input ref. Sadly, we can't (at least I can't find a way) change this prop. So, when the initialValues are defined, and if the user didn't change the fields, the _lastNativeProps is undefined. Then we fall back to the defaultValue.
The validation seems to work fine. Also the Scope and the resetForm.
I was creating this Draft PR to get some opinions about my approach. If all fine, I'll write tests and improve what is needed as soon as possible. Suggestions and reviews are welcome. I think that still have some redundant code (see the both lib/Form.tsx and lib/native/Form.tsx), and still thinking about how to achieve this.
Additional context
By making this, I got me trying to get the form data out of the handle submit function. I found what I think is a good way to make this (like the useSubmit hook). Will open an issue soon to discuss if it is welcome. 😃

Great @italomlp! I think that we should not duplicate our codebase as the elements itself, we should maybe adapt them to work when React Native is present. I will take a look at the code base and suggest something this week.

@diego3g I was thinking. In the way that I did it, the only things duplicated are the Form.tsx and the Input.tsx (all the other things are exported without duplicating them in native too, but only for the user don't need to import them from the default way). I believe that these components should be different in native, but as they have much code in common with the DOM version (the code of the main functionality), we can make a CoreForm.tsx, and reuse it properly in both DOM and native. What do you think about this approach? If good, I can do these changes tonight.
Another option is that we can check if Unform is running with react-native, and choose the proper component/element to use in Form.tsx and Input.tsx. But I confess that I don't like it this way. Seems like a quick fix/kludge to me. Only my two cents 😄 .

@italomlp Maybe Form element must be splited from Form component itself, i mean, we should not duplicate Form file between web and native version, maybe we should have an Form component apart from the functional part of form as parseData and all of the other stuff, what do you think? With that i think we'll be really close to a release candidate implementation.

@diego3g It's good too. I'll make it as soon as possible, and include tests too. About the submit approach and import way, all good?

@italomlp I think we should not have useSubmit hook, instead we should have an useForm hook that exposes more than the submit API, what you think about it? We are discussing it here #76.
We could have something like this:
import React from 'react';
import { useForm } from 'react';

export default function () {
  const [Form, { submitForm, resetForm, setFieldValue, getFieldValue }] = useForm();

  return (
    <Form />
  );
}

Another option would be not retuning Form from useForm and just retuning one way to connect the forms. Something like this:
import React from 'react';
import { Form, useForm } from 'react';

export default function () {
  const { submitForm, resetForm, setFieldValue, getFieldValue } = useForm('#myform');

  return (
    <Form id="myform">

    </Form>
  );
}

What do you think about this API?
@jpdemagalhaes can you give you thoughts on it?

@diego3g Yes, I confess that I thought about it from the begin haha. What I thought:
We can work only with hooks, transforming the main Form into one (maybe passing initialValues and other props like schema, etc. in the useForm hook), and use more or less like you described in the first approach. So, we export the Scope element, the Input element too (the core ones), like is already done, and use them normally:
import React from 'react';
import { useForm, Scope, Input } from '@rocketseat/unform';

const initialValues = {
  fullName: 'Italo Menezes',
  address: {
    country: 'Brazil'
  }
}

const schema = { // ... }

export default function () {
  const [Form, { submitForm, resetForm, setFieldValue, getFieldValue }] = useForm({ initialValues, schema });

  return (
    <Form>
      <Input name="fullName" />
      <Scope path="address">
        <Input name="country" />
      </Scope>
    </Form>
  );
}

The second way you suggested seems less powerful and less beautiful to me haha. Waiting for more opinions here.
If we use it in this way, could we make it in this PR (as I started this work with the submit) or open another one?

@italoiz I think the first approach is prettier too, but it will probably cause some problems with the current version so it will be a big change in unform. I would really appreciate a little bit more discussion here.
@jpdemagalhaes @pellizzetti can you share your thoughts about this?

@diego3g @jpdemagalhaes @pellizzetti I was thinking. I making an app with RN, and want to use Unform on it. I will do a bit of change accordingly to what we talk here, and use my fork while we decide things. Soon, you can see these changes on my repo (I will let a message here), review if it's ok and what has to be better to release that on official repo. Thanks

@italomlp I'm spending some time thinking about a full-hooks API so we can have all the functionalities we're discussing in this pull request.

I'm closing this draft PR, as Unform v2.0 will bring RN support out of the box. Thanks to the Rocketseat team!


Add code of conduct referenced in CONTRIBUTING.md

While I was looking at contributing to get started on the CMake work, I noticed this was missing.

@ethanhs,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by Microsoft. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot

Thanks! Not sure how the file went missing in the first place.


Review/897/distinguish fallback value and max value

This is the second part of my post-review work, dealing with the distinction between:

falling back on a db model attribute in case something isn't defined in the flex-model, and
making sure consumption/production capacities do not exceed a given power capacity.

I split this work into two commits, best considered separately:

49a155a62ed5b01f032d2c6f99ea940d1bcf6b68 deals with the distinction explained above, and
c1b24dd55c6c152bd274860550aa9dd6fbd54c97 deals specifically with the case of having gaps in the sensor data of the production/consumption capacity.

In the second commit, I'm proposing to fill these with the power capacity, rather than with the value coming from the fallback attribute. I realize I am proposing this with the consideration of obtaining a consistent policy throughout our API, more so than practical considerations for a given use case. That API policy being that db model attributes are only used as fallbacks for missing fields, rather than as limitations on fields, of flex-models sent through the API.
I'm open to discussing potential merits of deviating from this policy, of course, perhaps by hands of an example?

I refactored a bit further, which made for a much slimmer get_continuous_series_sensor_or_quantity method. Two more ideas, which I'll leave to you:

Renaming said method.
Looking up the fallback attribute already when deserializing the flex model. I believe that would make sense in conjunction with https://github.com/FlexMeasures/flexmeasures/issues/911, though it could/should be a separate ticket. That is, the flex-model field and db model attribute would both represent a serialized object and both be called "consumption-capacity", and the db model attribute is used as a fallback already before deserialization.

* Renaming said method.

Perhaps, we can make the function a static method of the class QuantityOrSensor and rename it to get_series, for instance. What do you think? It would look something like
QuantityOrSensor.get_series(quantity_or_sensor, start, end, ...)

However, this looks the same size if not more.
An alternative name could be get_regular_ts(...).

* Looking up the fallback attribute already when deserializing the flex model. I believe that would make sense in conjunction with [Migrate attribute names to use dashed to separate words #911](https://github.com/FlexMeasures/flexmeasures/issues/911), though it could/should be a separate ticket. That is, the flex-model field and db model attribute would both represent a serialized object and both be called `"consumption-capacity"`, and the db model attribute is used as a fallback _already before_ deserialization.

Good idea! This is a feature that we are going to find a lot and it's better to bring the functionality into the marshmallow field.

I'm expecting that moving the fallback logic into the schema will also lead to more clarity on choosing a new name for the util method. Maybe tackle those together.


Homology modelling: *nix only instructions

The homology modelling notebook currently has calls to the following which will not work on windows:
tr, wc, cat, cp
Furthermore, vim isn't a default install on most machines (be it Linux or Windows), and will need separate instructions. That being said, it may be better to switch to a gedit / notepad call.

Ah yes...  forgot about that and did after the initial test on windows.  Will suggest alternatives.

Similar to comments made on the docking tutorial, it might be cleaner to have two separate versions (especially given that Windows installs are generally more of a pain). I need to test out the tutorial locally, so if you want I can create the windows version whilst I'm at it @philbiggin ?

Now the instructions are unified for windows users - its slightly clunky in editing aspects but better than two different versions floating around.


Support MLX in WhisperAX

Add support for the WhisperAX example app, as well as various refactors and cleanup.

Note: this is using an unreleased version of MLX, pending merge of https://github.com/ml-explore/mlx-swift/pull/130
There are still some memory issues to address, will look more into this soon.
CoreML:

MLX:

Important note, first time running this will likely throw an error about PrepareMetalShaders, which requires Trust & Enable on this popup when selecting the error.

Hey all, just a heads-up, the example project gets this SPM error:

Hey all, just a heads-up, the example project gets this SPM error:

that fork was merged and is now the 0.16.2 tag on https://github.com/ml-explore/mlx-swift

Awesome, thanks for the update @davidkoski!

@ZachNagengast - This looks awesome! Apologies - rookie question... It looks like currently the MLX repo only has the base and tiny models. How hard is it for mere mortals to "build" some of the larger models for testing this out with larger models?

Or... can you use existing models with MLX?

Sorry missed your original message! We will fill in the mlx repo with the remaining models as part of this release, we just made these copies for consistency with our swift package. Any MLX whisper model currently existing with the same naming scheme will work in theory 👍  @jkrukowski may be able to confirm or deny.

Legend, thanks @ZachNagengast! So basically, we do need new models for MLX, we can use the existing WhisperKit models? They need to be optimised or something?

Yep the existing WhisperKit models are optimized for CoreML, the ones in this repo we will fill out with the equivalent weights that are compatible with this MLX PR

Sorry for all the rookie questions, but when you say "optimised for CoreML" - does this mean they ONLY work on CoreML, or can you use these CoreML models in MLX and they're just not as fast/accurate?
Apologies - this whole Whisper world is very new to me, so I very much appreciate all your wisdom and support!

Yep the existing WhisperKit models are optimized for CoreML, the ones in this repo we will fill out with the equivalent weights that are compatible with this MLX PR

Is there any model conversion script we can run, or any other source we can use, in order to create/obtain more MLX compatible model versions?

@latenitefilms Yes the .mlmodelc models only work with CoreML at the moment.
@maxlund There is a script made by @jkrukowski to do the conversion here https://github.com/argmaxinc/WhisperKit/pull/169, we'll integrate this into https://github.com/argmaxinc/whisperkittools in the future.

Legend, thanks so much @ZachNagengast! Do you have a rough/ballpark ETA of when you're hoping to finish and merge in MLX support? No rush or pressure - just wondering if it's worth trying to convert our own models or not.
Let me know if there's anything I can do to help with MLX testing/release! Would love to see this in action ASAP!
Thanks for EVERYTHING you do! Appreciate it!

There are just a few optimizations to fix up to make it ready for release, specifically memory usage. Current issues are:

MLX does not require a prewarm stage, so it should skip that. Currently its loading the model twice without freeing up the memory. Can also be solved by setting a cache limit or clearing the cache after load
KV cache should use this instead of mlmultiarrays
Sampling can be compiled for some easy speedups
Attention should use SDPA instead of current logic

These are paraphrased from @davidkoski and @awni
Will be revisiting this after the upcoming release but feel free to test with this current branch if you see any other potential speedup besides these, all the interfaces should be the same in its final form, just faster and more memory efficient with these changes.

Amazing! Thanks so much! Will test out and let you know if I break anything.

Any update on this? Is it usable? @latenitefilms @ZachNagengast ? Can someone please point me in the direction of how i can get this set up?

Hi @anishjain123 these are still pending issues https://github.com/argmaxinc/WhisperKit/pull/200#issuecomment-2395207140, but this branch is technically usable. We'd like to resolve the perf and memory issues before merging, which is still a high priority for us! Working on a refactor right now to allow various different model input and output types, including MLXArray, which should help with the issues converting between MLMultiArray and MLXArray.