Allow resetting the focus on SelectPanel

We are updating the labels picker in issues to not have a loading state, but instead just add more items from the server as they are loaded. This is causing the previously focused item to still be highlighted even if there are newer, more relevant options:
https://github.com/user-attachments/assets/1a527bf3-7430-4d07-8856-996cd41deea6
I understand from @broccolinisoup that the primer_react_select_panel_with_modern_action_list would solve it, but it's still a bit of a ways out before it's rolled out. She suggested I opened an issue to add an API to update / reset the focus on the list.

Thanks @alondahari for the issue.
Just additional notes for the triage session.

primer_react_select_panel_with_modern_action_list would solve it,

The flag inherently solves this just because it focuses on the first item not the previous one. I have to mention that though I am not sure if this is intentional. I'll confirm this behaviour with the accessibility team and provide an update here.

She suggested I opened an issue to add an API to update / reset the focus on the list.

We need to first check this with accessibility to ensure this is an accessible pattern then we can triage this.

Added to the SelectPanel feature improvements epic: https://github.com/github/primer/issues/3399, can you help me with the prioritisation. Does the epic have other features that you would like to see first. Alt: Is this something you consider a blocker or good to have.

@siddharthkp thank you for looping us in!

For prioritising this feature, I would probably say it's top priority for us right now since it's blocking us from improving the label picker experience, and we received a lot of negative feedback on it from our users.
implementing the loading state would also be great, but not a blocker to the above.
We'd love the create new item support, but we have a (not very good) workaround for now.
We are also interested in https://github.com/github/primer/issues/4027 for our pickers in the new issue dialog, but we have a workaround of giving the modal a fixed height (not ideal but works for us for now).

This would be also order of priority for us atm.

Thanks for that! I've moved this issue to Priority 1, the exact position is still TBD, but it's right there are the top for now

We need to first check this with accessibility to ensure this is an accessible pattern

Update: I checked this with accessibility and they recommend resetting the option to the first item. (Slack thread)
Rather than making where to focus optional (first vs previous) we might need to fix the code and make sure it always resets to the first item. Should we mark this as "bug" @siddharthkp ?

Just one comment, that we should make it so after more items have loaded the focus remains on the same "index" it was before. Unlike the workaround I just shipped, if you already used the keyboard to move down I'd expect the same position after we add more items. Here is how it currently behaves (behind a FF):
https://github.com/user-attachments/assets/301f1086-250f-436c-8884-6657d79cb554

@alondahari I am probably missing a great deal of context here so I appreciate any information 🙏🏻  - just wanted to ask if we have checked the original behaviour with accessibility before? Regardless where the focus is set, I am curious if loading the options dynamically and updating the list after is any chance considered distracting for both visual and screen reader users 🤔

👋
There are 2 scenarios to consider:

Changing all the items when searching for items

Should show an inline loader (in the input)
Focus should reset to the first item

Loading more items in the background below the previous items

Focus should stay where it is

Need to verify if this is how it behaves with the feature flag on.

@alondahari, looking at your video from https://github.com/primer/react/issues/5261#issuecomment-2478285880, it looks like the feature flag is not turned on, is that intentional?

@alondahari I'm curious to understand the reasoning behind your expectation that the focus remains on the same index as before. 🤔
I would personally think that it should be the same item (I'll double check with @siddharthkp to clarify his wording) after loading more items in the background. Mainly because after user navigates to a certain element, they might be about to make a selection and if we load new items and move focus to another item, even though the same index, this could be a distracting behaviour.
Also, I wonder if loading new items above the current list is an accessible practise - as I mentioned in my previous comment.

If we are loading more items above the focused item, we should not keep it focused since it's no longer the most relevant result and probably not close to any relevant result. I might see a possible approach of loading more and keeping only the focused item on top as the first result, but I have a feeling that would lead to some more jarring experience.
@ohiosveryown wdyt should be the behaviour here?

Focus should stay where it is
By "where it is" meaning the same index, not the same item, right?

Because the scenario i'm mentioning here is loading more items below the current items, it should not matter.

so if more items are added and before that the focus is on the 4th item down, after the items are added I would expect it to still be on the 4th item down, even if it's now a different item.

Sorry, this feels a bit off. Adding items that change the position of items seems a bit rough for user experience 😅 and probably not accessible?

If we are loading more items above the focused item, we should not keep it focused since it's no longer the most relevant result and probably not close to any relevant result.

This sounds like the scenario for filtering items, and in my opinion, we should reset the focus to the first item. This also aligns with the screen reader announcements built into SelectPanel. (See https://github.com/primer/react/pull/4968 for more info)

VSCode just reported this issue as well.

@ohiosveryown wdyt should be the behaviour here?

...we should reset the focus to the first item. This also aligns with the screen reader announcements built into SelectPanel. (See https://github.com/primer/react/pull/4968 for more info)

This makes the most sense in my mind as well.

I might see a possible approach of loading more and keeping only the focused item on top as the first result, but I have a feeling that would lead to some more jarring experience.

I agree, on the surface this might seem like a feasible solution, but it feels like it might be a little confusing / jarring.

I talked to @broccolinisoup and we decided to open a bug fix for primer to support the behaviour of always resetting the focus to the first item when we change the items on the list. She will add some pointers / notes to this issue and we'll pick it up as a part of our current initiative.


fix: re-configure node ID type after soft reset

After a soft-reset the controller uses 8-bit node IDs to communicate again, while Z-Wave JS was still assuming them to be encoded as 16 bit. This PR resets the assumed node ID type to 8 bit after soft-reset and tries to re-configure to 16-bit afterwards.
fixes: https://github.com/zwave-js/node-zwave-js/issues/6127
fixes: https://github.com/zwave-js/node-zwave-js/issues/6128

@zwave-js-bot automerge


Binary Classification vs Regression

I feel as if it would be a better idea to have a regression for predicted price for the next time window (whatever increment we end up choosing).
This is because, in the scenario the price goes up, it is only profitable to trade when the expected profit exceeds trade costs (gas). If we had context for the price increase we could avoid losing money on negligible increases.
Thoughts?

I definitely agree that a regression model is more appropriate for projected price/profit.
The main function of the classifier is generating a confidence value that the price will increase or decrease using a confusion matrix.
Perhaps we should split the trading pair scoring process into two separate models, a regressor and a classifier. These could be used to generate predictions for both reward (projected profit from the regressor) and risk (the confidence value for a price increase or decrease move). I think building these models for a variety of timeframes for all symbols (example: 1 min price change, 5 min, 15 min, 30 min, 1 hour) will provide the Q-learning trader with enough information to determine an optimized trading strategy that both reduces risk and rewards profit.

regression for prices, classification for tweets


[WIP] Gromacs engine

This is the Gromacs engine for OPS. Note that this includes #144, and should be merged after that.

This is ready for beta testing, which is why I made the PR. Since this is the first real usage of the external engine, I'd like to have a few experts put it through the paces before we deliver it to the general audience. This will be part of either the 1.1 release or the 1.2 release.
A few people who I hope might be willing to beta test (based on hearing that you need Gromacs): @jvreede @hejung (others feel free as well!)

Just as a short info: I started testing gromacs, including if everything works as expected for MARTINI.
I will create a list of things that I find here and edit this comment if the list grows.

Trajectory.to_mdtraj() does not work for Gromacs trajectories, it works if we use Trajectory.to_mdtraj(tra.topology.mdtraj); the reason beeing that to_mdtraj() checks for a (mdtraj) topology at engine.mdtraj_topology and gromacs engine has it at engine.topology.mdtraj.

Thanks @hejung -- I just added mdtraj_topology (the idea of a general engine.mdtraj_topology came after I had implemented most of the Gromacs engine).
Thanks especially for checking on MARTINI; that was something I was curious about. Are there no issues with topologies from MARTINI? This was one of my concerns (as in, that the engine can't even be built because the internal topology causes trouble -- maybe you can't export MARTINI trajectories to MDTraj, but that would be less of a concern.)

@dwhswenson I think there is a typo in the fix from yesterday. You named the property mdtraj_trajectory instead of mdtraj_topology

You named the property mdtraj_trajectory instead of mdtraj_topology

oops! Should be fixed now. This is why one should always include tests for everything! haha

Using gmx_engine.engine_command() before calling gmx_engine.set_filenames() raises an AttributeError since the output filename is not set yet.

Actually, this was easy to fix: in principle, one should always set all instance variables in __init__ anyway. Now it should return some placeholders -- let me know if you think the placeholder nature of the text should be made more clear by adding $ before names (currently all caps).

Setting nstxout and nstvout to zero in the .mdp file results in the gmx_engine never terminating, although gmx does (and possibly even generated a trajectory in .xtc format).

Added mention of restrictions on these values in the docstring. You're correct that we should also make this clear in other documentation (such as examples).

.gro files do not contain bond information.

I thought that MDTraj figures it out when you're working with residues it is familiar with (mainly amino acids). I've modified this so that you can set the mdtraj_topology property. That enables you to create an MDTraj topology according to whatever approach (e.g., using a PDB) and associate it with the engine. By default, it will use the one that MDTraj builds (and that will still be at engine.topology.mdtraj_topology).
For MARTINI, you'd probably need to build custom topologies. To create custom "elements", take a look in here. I'm not sure what will happen if you add an "element" whose symbol already exists (e.g., "W").
For now this custom topology override will not be saved/reloaded; I need to think about how to do that (you shouldn't be able to reload it and then change it to a different topology, because then the reloaded object is different from the saved object.)

I will look into adding MDAnalysis function CVs (which would take an MDAnalysis universe as input) as solution

This is something I've been interested in for a while. I haven't worked much with MDAnalysis, but it's definitely a package we eventually want to integrate with!

By the way, as you find more things, please feel free to add additional comments, instead of editing the existing. I get notifications on new comments, not on edits!

Concerning the bond info for atomistic simulations: I checked for ala, here mdtraj sets no bonds if using the .gro. But since grompp also takes .pdb as inputs (-c) at least since gmx v4.6, I think the easiest solution is to directly pass a .pdb instead of .gro to the ops gmx engine. This then results in mdtraj loading the .pdb instead of the .gro and reading the bonding information from there. So basically just another documentation change to inform users that giving a .pbd instead of a .gro might make their life easier. :)

@hejung : I updated the docstring for the gro argument to explain that other filetypes are possible, and best MDTraj integration may come from PDB. Thanks again!

A bit off-topic, but since it was last mentioned here:
I have a preliminary implementation of openpathsampling with a MDAnalysisFunctionCV (see https://github.com/hejung/openpathsampling/tree/gromacs_mdanalysis).
To get it to work I modified the openpathsampling.engines.openmm.topology.MDTrajTopology to an openpathsampling.engines.topology.MDTopology. This new topology is heavily oriented at the old, but now also stores the topology as MDAnalysis topology. To that end it has two classmethods that convert MDTraj topolgies to MDAnalysis and vice versa. (For now) it only saves the mdtraj topology to storage, but that should be sufficient since the round-trip MDAnalysis->MDTraj->MDAnalysis gives the same topology. Replacing the old with the topology results in all tests passing.
@dwhswenson Would this be a viable solution? In that case I would write tests and open a pull request from a clean branch where I rebased the changes on openpathsampling:master.
Concerning the gromacs engine: While writing the topology I realized that all other openpathsampling engines take a topology as input to __init__. This results in the user explicitly loading the topology as with openpathsampling.engines.openmm.tools.topology_from_pdb(). This in turn can minimize the assumptions made when loading topologies by requiring explicit flags (like MARTINI/atomistic; guess bonds; standartize names; etc). Getting these things right automatically seems hard to me so I would opt for making all engines taking an explicit topology. This would enable the user to e.g. load a MARTINI topology from .tpr with MDAnalysis and have everything work as expected (if using the new topology together with the custom MARTINI bead elements I defined even MDTrajFunctionCVs).

@dwhswenson Some additional info on the MDAnalysisFunctionCV since I realized I started writing where I stopped thinking:
The branch in which I added it is based on your gromacs_engine (I was not sure if I would need it), so this diff is probably most informative: https://github.com/dwhswenson/openpathsampling/compare/gromacs_engine...hejung:gromacs_mdanalysis
The essential addition is the new openpathsampling MDTopology, otherwise I oriented myself at how the MDTrajFunctionCV works, i.e. using Trajectory.to_mdanalysis() to call the MDAnalysisFunctionCV.

@hejung : Sorry for the delay; I spent the last week dealing with apartment-hunting stuff. Could you start a new issue with the MDAnalysis discussion? Regarding converting between topologies, I think this is really useful code, but I wonder whether it might be even better to put it into one of the other packages (MDAnalysis, MDTraj, or maybe something like ParmEd?) so it can be used by a broader audience -- after all, it would be useful to people outside the path sampling community.
The stuff specific to the CV wrapper looks mostly good. The topology stuff has a few points that I think might be better if done in a way that's more flexible (first step: instead of martini being a bool, have it be something like particle_set, which can be 'atomistic' or 'martini' or others, and create classes to handle specialized behavior for each -- this will make it much easier to, in the future, add support for particle models). We can discuss this in more detail in the separate issue.

Getting these things right automatically seems hard to me so I would opt for making all engines taking an explicit topology. This would enable the user to e.g. load a MARTINI topology from .tpr with MDAnalysis and have everything work as expected

I was aiming to require minimal input from the user. If added, a separate topology argument would be an optional argument for __init__. There's a topology that is implicit from the Gromacs input files, and for many users, that will be sufficient. If the user provides an override, how can we verify that the user-provided topology is for the same system as the one determined from the inputs? The fear here is that the user might do something that doesn't make sense -- but maybe checking number of particles is enough?
In general, I think we want to keep the simplest setup as simple as possible, and as much like the native engine (helps new OPS users). OpenMM's Simulation class requires a topology, system, and integrator, so the OPS engine requires the same. For Gromacs, grompp requires files for the -c, -f, and -p arguments, so the OPS engine requires those files. Additional things beyond that would be optional, but we need to consider potential conflicts. (The existence of a topology argument in the toy engine comes from a long debate between me and @jhprinz.)
Overall, I think our topology objects need to be significantly restructured. I often don't know whether something is supposed to take an OPS topology or an MDTraj topology (or maybe an OpenMM topology?) But that will probably be API-breaking, and has to wait for 2.0.

@hejung @jvreede Checking in with people who have been beta-testing this: Does it seem ready for production? If so, I'll remove the WIP status from it, and it will be ready for review.

Hi @dwhswenson . Where can I find an example notebook which uses Gromacs as an engine ?
I realized you had made one with alanine dipeptide but cant locate it online

@arjunwadhawan It's only in the branch for this PR -- since the Gromacs engine hasn't been merged into the master, it wouldn't make sense to have the example in master yet.
With a developer install of OPS, check out this branch, and you'll see it in the examples. You can also find the notebooks (and related files) here: https://github.com/dwhswenson/openpathsampling/tree/gromacs_engine/examples/gromacs

Ah alright. Makes sense. We are going to use it and will get back if any issue
Thanks

Recent commits address stuff discussed in #855.

The most recent commits are not backwards compatible with files generated by earlier versions of the OPS Gromacs engine. Here's the explanation and the workaround:
What changed and why?
Now OPS will store the contents files used to set up the simulation (e.g., .gro, .mdp, .top) inside the engine when saving the engine to our .nc storage.
OPS simulation objects should be immutable (at least, mostly). When you reuse an engine, you should always get the same behavior.
However, until these commits you could reload an Gromacs engine from storage, and change the behavior of the engine by changing the files. For example, you could change the integrator by editing the mdp file.
This is a problem because we want to ensure that you have a record of provenance in your data: you should to be able to tell exactly what integrator was used to create a specific snapshot.
In the new implementation, OPS will check for the existence of a file with the correct name. If it doesn't exist, OPS will create the file (writing the stored contents to disk). If it does exist, OPS will check whether the sha1 hash matches the hash of the stored data. If so, it uses the existing file. If not, it raises an error.
We raise an error on mismatch because we're not sure whether wanted to use the engine as is (in which case, maybe you don't want to overwrite the file?) or if you thought that you could change the behavior by changing the file (which breaks immutability and provenance checking).
Why will this raise an error with existing storages?
Before these commits, the file contents weren't stored. When OPS tries to reload the contents of these files from our nc storage, the engine will fail to load. For some reason, it appears to fail silently, too -- so you'll get None for the engine. (This is behavior that will be different in the new storage.)
How can I work around the error?
Write a custom from_dict function and monkey patch it to the engine class (before reloading!):
from openpathsampling.engines import gromacs as ops_gmx
def custom_from_dict(cls, dct):
    return super(ops_gmx.Engine, cls).from_dict(dct)

ops_gmx.Engine.from_dict = classmethod(custom_from_dict)

Note that after monkey-patching, you will (within a given Python session) only be able to load old-format engines, but will store in the new format.
Tagging people who might need to know this: @hejung @arjunwadhawan @IdsTeepe

I'm calling this one ready for review (FINALLY!!) The last changes were to move the ExternalMDSnapshot out of Gromacs-specific code (because it can be used by other engines, too) and to make the ExternalEngine abstract, putting a subclass with the reference/test implementation in the test suite.
This is a huge PR, and includes #144, which will not be merged separately. I'll leave this up for a week for review, merging no earlier than Saturday 7 December. If anyone is actually going to review it and wants longer than that, let me know. If there are no comments expressing an interest in reviewing, I'll assume everything is okay, and will merge.
I plan to release 1.1 shortly after merging this.
Thanks to @hejung  and @IdsTeepe for doing some real-world testing of this PR. Just to make sure everyone who might care is getting the message: @jhprinz @arjunwadhawan.


Docs: remove note about jobs without schedules.

cc @elingg

Thanks for adding clarity to the docs! :+1:


feat(ktable): add clickable rows and links - khcp-106

Summary
Added clickable rows and links to KTable.
Changes made:
*Made rows clickable to navigate to another page
*Made inline links in rows
*Added metakey support for clicking
PR Checklist

[x] Does not introduce dependencies
[x] Functional: all changes do not break existing APIs and if so, bump major version.
[x] Tests pass: check the output of yarn test packages/
[x] Naming: the files and the method and prop variables use the same naming conventions as other Kongponents
[x] Framework style: abides by the essential rules in Vue's style guide
[x] Cleanliness: does not have formatting issues, unused code (e.g., console.logs), or leftover comments
[x] Docs: includes a technically accurate README, uses JSDOC where appropriate

https://github.com/Kong/kongponents/pull/231 needs to be merged first


add more hint when chosen backend failed

What type of PR is this：

[ ] bug
[ ] feature
[x] enhancement
[ ] others

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

[FE PR Coverage check]
:heart_eyes: pass : 5 / 5 (100.00%)
file detail

path
covered line
new line
coverage

:large_blue_circle:
com/starrocks/catalog/Catalog.java
5
5
100.00%


API Error

Hi,
following error recived:
An error occured accessing AlexaAPI: An exception of type JSONDecodeError occurred. Arguments:
('Expecting value: line 8 column 1 (char 7)',)
Then may be a followup error:
Mon Apr 01 2019 14:33:04 GMT+0200 (Mitteleuropäische Sommerzeit)
Error doing job: Future exception was never retrieved
Traceback (most recent call last):
File "/usr/local/lib/python3.7/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/config/custom_components/alexa_media/init.py", line 450, in
track_time_interval(hass, lambda now: update_devices(), scan_interval)
File "/usr/local/lib/python3.7/site-packages/homeassistant/util/init.py", line 224, in wrapper
result = method(*args, **kwargs)
File "/usr/local/lib/python3.7/site-packages/homeassistant/util/init.py", line 224, in wrapper
result = method(*args, **kwargs)
File "/config/custom_components/alexa_media/init.py", line 276, in update_devices
for device in devices:
TypeError: 'NoneType' object is not iterable
Notification does not work

Ok, please close. Maybe solved. I moved the login to !secrets. Amazon wanted to get a new captcha. Haven't seen that.


Add license

I am not sure we will get any feedback. Let's merge this using<EMAIL_ADDRESS>email instead of the one you listed.

@petrknoth asked us to wait so let's wait.

Sorry, sure, this is not urgent. @petrknoth do you have any better suggestion for the license?


Assessment model results section - recruitment sub-section

Last paragraph:
I also get 1.43 for SD across 1971-2012.  But I get 1.56 for SD across 1966 - 2014 (begin of bias adjustment period).  Should we be reporting all the way back to 1946? I'm not sure what that tells us?

I think that reporting only 1971-2012 is relevant. Not sure what it means
to report those non-informative years.
On Mon, Feb 8, 2016 at 1:30 PM, aaronmberger<EMAIL_ADDRESS>wrote:

Last paragraph:
I also get 1.43 for SD across 1971-2012. But I get 1.56 for SD across 1966

2014 (begin of bias adjustment period). Should we be reporting all the
way back to 1946? I'm not sure what that tells us?

—
Reply to this email directly or view it on GitHub
https://github.com/cgrandin/hake-assessment/issues/84.

Agree, go ahead and delete the 1946-2014 values.

done and closing


Historic capacity is dropped in merge of residual and New capacity

I observe that the original ResidualCapacity is being dropped and only the NewCapacity is passed on.
Would you have time to have a look @trevorb1?

I think I figured out what is the issue. Not sure why the test didn't realise it.
When merging NewCapacity of the just run step with the ResidualCapacity of the steps to come we only read in once the ResidualCapacity, the one of the next step, i.e., for later steps the ResidualCapacity is not considered, unless the foresight horizon is rather long.

Closed with PR #75


Non-Acceptable Nickname Detection System

Description
This system will contain a few checks that will be triggered on the event on_message, the display_name of the message author will be checked, and if found abusive to our rules, will be reported or logged.
The checks should be fast and simple to prevent long and heavy calculations that are triggered on each message, but we can expand them to fit our needs.
Solution
Changed the solution to @ikuyarihS Suggestion-
The previous check ignored mentionable parts of the user and it shouldn't
For example ハーリさん (CF8) is a fine name
It is mentionable with @CF8
Partial checking instead will make it better, like
any(map(str.isalnum, name))

Or make that even stronger - we count how many char is mentionable, 3 is a good count
sum(letter.isalnum() for letter in name) >= 3

We can use REGEX for more specific checks.

Think a good idea would be to check if the user has any Unicode, to begin with, before checking how many ASCII characters they have. I would just require a simple check if their entire name is ASCII why bother counting it. Just reduces the number of times calling a loop, altho minor.

The check for any Unicode by itself requires a loop over the string, so in that light might as well reduce it to a single loop of counting how many mentionable alnum in my opinion.
The deal breaker will be how we can make it not spammy, so it will trigger once per user per day perhaps.

wouldn't just <name>isascii() work for skipping over that loop? if the username is MyUsername#6621 it will be true, so we could just do if not <name>isascii() then check using the loop

Okay, so I've discussed this with the admins and moderators, and we have several comments. @F4zii Please use these comments to reformulate the original issue text and change what this issue is going to solve.

We don't care about detecting names which are hard to mention. It's overkill, todays current system works fine. Let's not do that.
However, we might want to detect nicknames that have bad words in them. You can use the same wordlists we have in the regex filters.
On that note, this should be implemented as part of the Filtering cog, especially considering the overlap between this and the regex filter (formerly word and token filter).
This should be detected on_message, but we want a long cooldown so we don't get notified that often - maybe 3 days.
There is no need to ping moderators about this when this filter triggers. This will be a pingless alert.
The correct channel to deliver this to is #mod-alerts (ID:<PHONE_NUMBER>47060736)
Only check the users display_name, not their username. If they have a nice nickname and an awful username, we don't care.

Please pivot this issue to incorporate all of these directions, and then you have my approval.

About the cooldown itself @lemonsaurus
the check cooldown will be per user ? or just the cooldown of being notified?

per user, yeah. We don't want to be notified of the same user every time they send a message, right? that would just be spam.

Could use just some simple dictionary with a timestamp to keep it quick and just check if timestamp diffrence is past a certain point

Something like that. Honestly, cooldowns are a solved problem in the bot, so just do it however we're doing it in other cogs. Ideally in a DRY way.

Maybe a warning over dm or in channel could be issued to the user with the inappropriate nickname as well?

Maybe a warning over dm or in channel could be issued to the user with the inappropriate nickname as well?

This sounds like automoderation, which we don't want to do. Our bad word filter has false positives, and I don't want it DMing users when that happens. It's better to let our moderators make these kinds of decisions.

I think this should listen for on_member_update event, not on_message because on_message will be called too much. on_member_update should check is display_name changed and when it is, do check.


mindspore.nn.Conv1d and mindspore.nn.Conv1dtranspose 's shapes are four-dimensional

Environment
Hardware Environment(Ascend/GPU/CPU):
CPU and GPU
Software Environment:

MindSpore version (source or binary): 2.2.14
Python version (e.g., Python 3.7.5):3.0
OS platform and distribution (e.g., Linux Ubuntu 16.04):Ubuntu 20.04

Describe the current behavior
The parameter shapes of mindspore.nn.Conv1d and mindspore.nn.Conv1dtranspose are four-dimensional, causing the model to be unable to complete the reading of the parameters. The dimensions described in the official documentation are supposed to be three-dimensional, and other frameworks such as TensorFlow and PyTorch are also three-dimensional.
Describe the expected behavior
Their parameter shapes should be one-dimensional
Related log / screenshot

same as issue228

你好。确实存在上述差异，MindSpore的Conv1d底层使用Conv2d算子实现，对于 kernel_size 等参数会在第0维进行自动补0操作，导致初始化的权重weight比PyTorch多一维，正常使用不感知，但涉及网络模型迁移时，通过参数加载的方式调用Conv1d可能会出现权重维度不一致的情况，需要用户手动对weight权重在对应维度上进行升维。
详见 conv1d差异faq


Missing Details in README and code

In paper you've mentioned,

For each epoch, we sample a maximum of 100 utterances from each of the 5,994 identities

In code that propagates as value of nSpeakers args parameter for angular prototypical. To derive result shared in paper what value of nSpeakers is used  for non softamx losses?

Both prototypical and angular prototypical, has hyperparmeter M. How to set that parameter in code ?(For other losses there is option to pass values m  and s in args).

This is related approach for evaluation and  does not require correction: You have used Euclidean norm for similarity.  Many earlier work on speaker verification including voxceleb used  cosine similarity. I evaluated result with cosine similarity and EER comes to  2.2693 . Slightly higher but not  by large.  Any reason to use Euclidean norm  over cosine  similarity?

This line

For each epoch, we sample a maximum of 100 utterances from each of the 5,994 identities

equates to --max_seg_per_spk=100 in the code.

For metric learning losses, --nSpeakers argument should be the value of M. For best performance on the VoxCeleb1 test set, use --nSpeakers=2. These parameters are described inside trainSpeakerNet.py

If the embeddings are L2 normalized, the squared Euclidean distance is directly proportional to the cosine distance. The order of distances (and therefore EER) should remain the same no matter which of the two distance metrics is used.


Fix typo in README.md

Fixing a small typo :)

I'm closing this PR since it seems that the project development has been suspended.


Update the XML spec

This PR updates the XML spec with the Windows 10 TH2 release version (10586).

LGTM

:+1:


Updated dead link check

Type of PR

[ ] Documentation changes
[ ] Code changes
[ ] Test changes
[ ] CI-CD changes
[x] GitHub Template changes

Purpose of PR

added missing file
updated template

Issues Closed or Referenced

Closes #17
Closes #21
Closes #27

@AAkindele - I think this closes 21 as well but won't know for sure until after the merge because ci-cd runs from master


gerrit-274977-7

Current coverage is 59.69% (diff: 100%)

Merging #62 into master will decrease coverage by 3.00%

@@             master        #62   diff @@
==========================================
  Files           265        265
  Lines         50105      49988    -117
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits          31416      29838   -1578
- Misses        18689      20150   +1461
  Partials          0          0

Powered by Codecov. Last update f8f8814...6bf9e10


bubble chart missing clipping?

This report follows a discussion on chartjs-zoom-plugin: https://github.com/chartjs/chartjs-plugin-zoom/issues/266 where zooming a bubble chart can lead to bubbles being drawn outside the chart bounds:

Expected Behavior

Expected the bubbles not to be drawn outside of the chart bounds.
Current Behavior

Bubbles are drawn over the title, legend, y-axes and x-axes
Possible Solution

A workaround is available, by making the radius of bubbles scriptable, checking the bounds of the chart and setting the radius to zero if outside, see https://jsfiddle.net/otcjx5yv/ but Im guessing that drawing bubbles outside of the bounds of the chart is a bug.  Ideally one would have the option of clipping bubbles that overspill outside the chart area or allowing a bubble whose centre is within the chart bounds to spill over into axes.
Steps to Reproduce (for bugs)

jsfiddle: https://jsfiddle.net/2qr50z18/1/
Context

I was trying to visualise some time series data with bubbles using a time x-axis and a category y-axis.  The category y-axis has labels which can be completely occluded when zooming.
Environment

Chart.js version: 2.9.3
Browser name and version: firefox latest (74) and chromium latest (80)

Here's another fiddle: https://jsfiddle.net/frgpk10j/
Also, I can reproduce it with https://www.chartjs.org/samples/master/charts/bubble.html though you may have to refresh a few times since the data is generated randomly
https://github.com/chartjs/Chart.js/pull/6642 added clipping and it looks like bubble chart was intended to be supported. I'm not sure why it doesn't work

Works in master (default is to allow half of bubble to overflow)
https://jsfiddle.net/qvm5athc/
The zoom plugin does not work though (probably because axes are configured differently)

The only thing the zoom plugin does is set the min and max on the scales

Based on the fiddle by @kurkle I think we can call this resolved in v3

Hello @etimberg
I just copied the code from the workaround ( https://jsfiddle.net/otcjx5yv/ ) to make it work in my environment,  but some error occured after compiling => "z' does not exist in type 'ChartPoint'"
I tried to replace z with r because ChartPoint for bubble is (x, y, r)  and this is not (x, y, z)
There are no errors, but radius function is not triggered and the behavior is the same as before
However if I keep z, even if there is this errors after compiling, the workaround works just like in the example
So what is z and why are using this instead of r ?
I have the same version of chart.js (2.9.2), using it through Angular on a centos 7.3


Deprecation notice and addition of docs to the main repo.

I have added a deprecation notice to the readme and dumped all the documentation into the docs.* folder.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[PE-D][Tester A] Cannot add a different person with same name

If there is two person with same name but have different phone, address and email, this program will not accept it.
Reason being that there are alot of people in the world with the same name even in facebook and google has many people with the same name.

Labels: type.FeatureFlaw severity.Low
original: LolfoollorS/ped#10

I personally feel that this should be made a known limitation. If we allow for duplicate names, then there will be other people commenting that duplicate names are also bugs itself.

Probably it can be clarified in the UG.


De-duplicate inherited coordinates & dimensions

[x] Closes https://github.com/pydata/xarray/issues/9475
[x] Tests added
[ ] User visible changes (including notable bug fixes) are documented in whats-new.rst

Superceded by #9555


Decrease websocket reconnect period

Not the nicest solution, but waiting for this issue, which doesn't seem to be solved soon
https://github.com/python-websockets/websockets/issues/1395

It is possible to do 500ms reconnect like in the JS SDK?


Setup mvc

In this branch I implemented the following
*Created a rails app called budget app

Add devise and linters to my rails app
Created models, controllers, and views for user, payment, and category
Styled my app according to the given design
Add test for models and integration test using capybara
Add descriptive readme

Thank you @danmainah for your insightful and thorough review, and also for the suggested changes and advise, I will implement them right away.


Make the environmental variable optional

What would you like to share?
Make it possible to open and run the code without adding an github token. Update the readme to reflect the changes and explain what happens with and without the token.
Additional information
No response

@Cahllagerfeld shall I close this issue? I recall you saying it might not be possible?


Oops, duplicate of #518

https://github.com/LockerProject/Locker/issues/518
On Thu, Jan 26, 2012 at 1:06 PM, Kristjn Ptursson <
<EMAIL_ADDRESS>
wrote:

First it's confusing that there's a radio button with no friends, and it
gets worse when it behaves like a checkbox (appears and disappears the
rename field).

Reply to this email directly or view it on GitHub:
https://github.com/LockerProject/Locker/issues/638

--
Merci Victoria Grace
Playful Designer + Producer
http://artserf.net
http://linkedin.com/in/merci
http://twitter.com/merci


edited 'should not' to 'should'

I assume we "should have a public / private keyboard located at ~/.ssh/id_rsa.pub and ~/.ssh/id_rsa respectively."


[Mesheryctl][Kubernetes] Replace latest with exact version after fetching manifest files

Description
Read #2610
This PR fixes #2610

@piyushsingariya with the latest discussion with @leecalcote on the development call, we concluded that we should fetch the specific docker image only for the meshery image and not the images for the other components like the specific adapters.
I guess that is the functionality currently and we can remove the commented out part. I will review this and merge after that change.

@piyushsingariya @leecalcote From our recent discussion, if the user wants to pin the adapter images to a specific version, they can do it by modifying the image tag in the meshery.yaml file.
So the scope of this PR is satisfied and we can merge this.

Excellent. Sounds good to me. Good work, @piyushsingariya


add font-face

Codecov Report

Merging #24 into master will decrease coverage by 1.24%.
The diff coverage is 50%.

@@            Coverage Diff             @@
##           master      #24      +/-   ##
==========================================
- Coverage   80.73%   79.49%   -1.25%
==========================================
  Files          11       11
  Lines         379      395      +16
  Branches       65       67       +2
==========================================
+ Hits          306      314       +8
- Misses         60       67       +7
- Partials       13       14       +1

Impacted Files
Coverage Δ

src/index.js
69.23% <0%> (-15.15%)
:arrow_down:

src/inline.js
100% <100%> (ø)
:arrow_up:

src/babel.js
96.36% <80%> (-1.64%)
:arrow_down:

Continue to review full report at Codecov.

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


MaxFlowDate_M (and other Date parameters) shown incorrectly "230,207.0 yy:mm:dd"

Did you read the instructions?

[X] I have read the README.

The problem
Ever since I'm using this integration for a Kampstrump 402 all parameters read that are supposed to hold a date are not shown correctly in HA.
as is:
"MaxFlowDate_M" holds "230,207.0 yy:mm:dd" as value
expected:
23-02-07 (or in a other date format that makes sense)
All other Parameters that are holding dates exhibit the identical issue

What version of this integration has the issue?
2.2.0
What version of Home Assistant Core has the issue?
latest
Home Assistant log
No response
Diagnostics
No response
Additional information
No response

Well spotted, everything is considered as a number right now.
I will fix it and parse them as date times soon.

Hey Sander, noticed this also... just got my 403 installed yesterday (you might remember me from the MC66C) and found a bug in the Kamstrup. From what I've evaluated until now, all values including their unit (or explain) of measurement are received as data packages and have to be transitioned sometimes. I made a pull request.
Then there is this incorrect unit of measurement for Tempdiff in K(elvin) which translates to celcius with temperatures below -200°C! Wonder how many developers have a workaround for that not informing Kamstrup.
Any idea if the Kamstrup Meter Protocol (KMP) is available anywhere? I read somewhere that they don't want to give the protocol details to private individuals. Okay, I like a challenge :) I'll drain it completely if I have to. Most important is the Info-event parameter that will inform us of an nearly empty battery.

Hi @HAEdwin
Your issue/question doesn't have much to do with the original issue, please create a new issue next time.

Then there is this incorrect unit of measurement for Tempdiff in K(elvin) which translates to celcius with temperatures below -200°C! Wonder how many developers have a workaround for that not informing Kamstrup.

According to the technical description document, the unit for tempdiff is K
https://koce1-kamstrup.ocecdn.oraclecloud.com/content/published/api/v1.1/assets/CONT46E54F336D7047A7907749B26DD3576C/native/55121689_M1_EN.pdf?channelToken=ed241bbb18f444908a8fc9ed97ca5d5bpage 2
The reason why K is correct, is defined in the SI Brochure:
https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf/2d2b50bf-f2b4-9661-f402-5f9d66e4b507?version=1.11&t=1671101192839&download=true page 133, quote:

The unit of Celsius temperature is the degree Celsius, symbol ○C, which is by definition
equal in magnitude to the unit kelvin. A difference or interval of temperature may be
expressed in kelvins or in degrees Celsius, the numerical value of the temperature
difference being the same in either case. However, the numerical value of a Celsius
temperature expressed in degrees Celsius is related to the numerical value of the
thermodynamic temperature expressed in kelvins by the relation
t/
○C = T/K − 273.15

If you don't change the unit in HA, it should remain the correct value.

Any idea if the Kamstrup Meter Protocol (KMP) is available anywhere? I read somewhere that they don't want to give the protocol details to private individuals. Most important is the Info-event parameter that will inform us of an nearly empty battery or other issue in the circuit. There will be some human logic in the protocol.

AFAIK the protocol isn't available and only reverse-engineered by Poul and then shared all over the web, more info: https://github.com/golles/ha-kamstrup_403/tree/main/custom_components/kamstrup_403/pykamstrup

@Kugelfang666 I've implemented the change in PR #75 would you be able to test these changes locally?
The branch name is 70-maxflowdate_m-and-other-date-parameters-shown-incorrectly-2302070-yymmdd I'll also test it in the coming days, you can see some screenshots in the PR from my prod instance.

Thanks for the quick fix! I just tried the branch and can confirm its also working for me!

This has just been released in 2.3.0


Remove strategy: fail-fast

Setting strategy: fail-fast has no effect unless the workflow is run as part of a matrix build. It controls whether one matrix build failing causes other builds in that same matrix to be aborted. It has no effect within an individual run.
See https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstrategyfail-fast for more info.
I'm removing this from the suggested usage example because it is unnecessary and misleading.
Merge / deployment checklist

Run test builds as necessary. Can be on this repository or elsewhere as needed in order to test the change - please include links to tests in other repos!

[x] CodeQL using init/analyze actions
[x] 3rd party tool using upload action

[x] Confirm this change is backwards compatible with existing workflows.
[x] Confirm the readme has been updated if necessary.

I'm not sure. I also remember removing it.


⚠ Bofrost.de has degraded performance

In eed68d1, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 991 ms

Resolved: Bofrost.de performance has improved in ef70e42 after 6 minutes.


tests: deduplicate pcaps, cleanup extras - v4

Rebase of https://github.com/OISF/suricata-verify/pull/1381.

Passes GitHub CI, but fails elsewhere.


Fix for #395

Better fix for #395

With this methodology in mind from #396

@an-tao sorry just a bit busy at work currently, my validation criteria for such PRs is that, after running make install (or ninja install, etc.) the *targets.cmake for drogon and trantor link to library targets (e.g., OpenSSL::SSL) rather than hard-coded include paths and compiled library paths (e.g., /local/path/to/ssl/libssl.a) etc. Can take a closer look some time later probably

This keeps the target files relocatable, you can also check these files in [builddir]/CMakeFiles/Exports/lib/cmake/Drogon
and
[builddir]/trantor/CMakeFiles/Exports/lib/cmake/Trantor
They both contain no absolute paths.


Units for ihm_external_files.file_size_kb?

The dictionary is unclear what the units are for ihm_external_files.file_size_kb. Are "kilobytes" old-style (1024 bytes) or new-style (1000 bytes)? If the former, it would be clearer to say "kibibytes". Either way the multiplier should be stated in the dictionary so it's clear.

Maybe making it ihm_external_files.file_size in bytes would be better.


unrecognized arguments: -forwarded-allow-ips=*

What can this mean? This happens in local development using dockerization at https://github.com/pvarki/tilaa.pvarki.fi/tree/feature/initial
pvarki-api                | usage: gunicorn [OPTIONS] [APP_MODULE]
pvarki-api                | gunicorn: error: unrecognized arguments: -forwarded-allow-ips=*

Ah, docker-compose pull probably fixes this.

Nope, pull did not fix it. The problem has been fixed in the Git two hours ago, but image seems to be using the old entry file still.
https://github.com/pvarki/python-pvas-arkia11napi/commit/f50c923836ab3242475d7725fe6c3eb8445f7ac2

Check your hash, make sure you're pulling from pvarki org not the old pvarkiprojekti one
docker inspect pvarki/arkia11napi
[
    {
        "Id": "sha256:603181da531ae854c9e84fb4f5b030ce06dcb9d49c7b022f65ddb293072b72f7",
        "RepoTags": [
            "pvarki/arkia11napi:latest"
        ],
        "RepoDigests": [
            "pvarki/arkia11napi@sha256:3036c0cb635d3a2ef21701239f4449ac9c28eb11eb2f3ddd2cf9c2d8fa326ada"
        ],

suitable-raptor is running that version

Thanks. That was it! :)


[Test] Add more useragents

https://github.com/ua-parser/uap-core/tree/master/tests
I think these lists are pretty conclusive

new list https://github.com/ua-parser/uap-core/tree/master/tests

also add a popularity field in there (in 0.x) this way we can sort on popularity and prefer populair ones


Fix constness warnings for AVOption

All AVOption manipulation should be done on const pointers, including
the AVClass.option definition, see:
https://www.ffmpeg.org/doxygen/4.0/structAVClass.html

Cherry-picked.


edit on some typing

before the edits, it gives me the compilation error message TypeError: 'type' object is not subscriptable and gives me errors when running pre-commit run --all-files.
after the edits, it runs perfectly and when running pre-commit command it works too

Thanks @abdoafage


Add additional columns to the Sponsor Portal

Additional columns for the Admin was created (like description) and that it working like a charm. (in #31)
It would be great if we also could get the possibility to have those extra columns on the sponsor portal.
In other words the request is to get the same functionality regarding the extra columns for the sponsor portal, that the Admin portal already have got.

@Jumb0Fr4m3 had some unexpected free time and was able to knock this out.  Pushing up to master branch and will close this issue out :)

Thanks.
I am able to do filtering on the fields that are already present, but when entering something in the description filter field, nothing happens.
Also I see that when I check the description under Column Visibility and do a refresh, the description field is gone and I have to check it again. It would be great if my preference could be saved.

It looks like broke on commit 12f4f5a when the different supporting tools where upgraded.   The issue is the logic that dos the search just returns column 0 for the current column.  I'll have to dig deeper into this one.  I'll make a new issue for it.


Linux agent depends on libicu52 but isn't listed as a prerequisite

Agent version and platform
Ubuntu 16 LTS / 2.100.2
OS of the machine running the agent?
Ubuntu 16 LTS (But running in Linux Subsystem for Windows)
VSTS type and version
VisualStudio.com
What's not working?
After installing prerequisites and downloading/extracting the agent, running ./config.sh fails with
Failed to initialize CoreCLR, HRESULT: 0x80131500
Workaround
wget http://security.ubuntu.com/ubuntu/pool/main/i/icu/libicu52_52.1-3ubuntu0.6_amd64.deb
sudo dpkg -i libicu52_52.1-3ubuntu0.6_amd64.deb

We build the agent for ubuntu 14 and ubuntu 16.  The 16 build does not need libicu52.  But we had a bug where we were only offering the ubuntu 14 agent in the download (should be fixed now).  If you try and run an agent built for 14 on a 16 box, you will see this.  Please confirm.
https://github.com/Microsoft/vsts-agent/blob/master/docs/start/envubuntu.md

Per comments above, not an issue.  Reactivate if you have more info

Sorry :( I forgot to try and repro. I need to do it on a clean machine, and when I do I'll let you know.

Okay, new machine (luckily I just got a new work computer):
Installed Ubuntu Subsystem for Windows
~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description:    Ubuntu 16.04.2 LTS Release:        16.04 Codename:       xenial
ran:
~$ sudo apt-get install -y libunwind8 libcurl3
~$ git --version
git version 2.14.1
~$ mkdir vstsagent && cd vstsagent
~/vstsagent$ tar zxvf ~/Downloads/vsts-agent-ubuntu.14.04-x64-2.123.0.tar.gz
./config.sh
Outputs:
Failed to initialize CoreCLR, HRESULT: 0x80131500

Oh boy PEBKAC
The default agent download is 14.04-x64. Clicking the different agent versions on the left side doesn't change the page look at all, maybe the download button should be more specific? "download for Ubunto 14.04-x64"?
Anywayyyyyyy entirely my fault, nothing to see here.

Good point.  Default should be 16.  Sorted 14 first.
Also note that we had a bug that sprint where 16 didn't show up so it may not have been your fault :)

Also - very soon, we will just a "linux" agent.

@bryanmacfarlane, can you give any updates on 'very soon'? I'm part of a project where we utilize vsts-agent and found that vsts-agent does not run on current Debian Stable. Oldstable works still.
I assume that "just a linux agent" is the same as "moving our agent to core clr 2.0 self contained app" as you mentioned in another issue and both will become true very soon.
Thanks,
mingalsuo

It's coded and we're testing.  We're hoping it rolls out in this sprint.  Should be week(s) away.  We can provided a private if you want.

@bryanmacfarlane, private beta? Sure :)

send me a mail.  bryanmac and that's at microsoft dot com


[$500] App displays 'Most recent' for some time after login and also does not change background color when value is changed

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Open the app
Open settings->preferences->priority mode
Copy the URL and change value to '#focus'
Logout and paste the URL
Login and observe that for some time, value is displayed as 'Most Recent' and once it changes to '#focus', background is still highlighted for 'Most Recent'

Expected Result:
App should display correct priority mode on login and also maintain background highlight over correct value
Actual Result:
App displays 'Most Recent' as selected value even though '#focus' is current selected priority mode on login and also maintain background highlight is maintained on 'Most Recent' even when value is rectified
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[x] Android / Chrome
[ ] iOS / native
[x] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: 1.3.74-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/43996225/c12086ff-1153-4917-b467-d2ceec44abc5
https://github.com/Expensify/App/assets/43996225/29a5e891-d61d-4d6b-86ff-9ca90ef28d50
Expensify/Expensify Issue URL:
Issue reported by: @dhanashree-sawant
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693324854860599
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~017588740c0155fa37
Upwork Job ID:<PHONE_NUMBER>822575104
Last Price Increase: 2023-10-02

Proposal
Please re-state the problem that we are trying to solve in this issue
App displays 'Most recent' for some time after login and also does not change background color when value is changed
What is the root cause of that problem?
The root cause of the problem is that we currently doesn't display a loading while app data is still being fetched, that way user can interact with select list before the data is fetched from ybackend.
My proposal is to add a loading screen.
What changes do you think we should make in order to solve the problem?
I recommend adding a FullScreenLoading component, similar to the LegalNamePage.js:
https://github.com/Expensify/App/blob/70e9fa0a77aba91abd12d8d0023ce10e7bfe80a7/src/pages/settings/Profile/PersonalDetails/LegalNamePage.js#L80
At:
https://github.com/Expensify/App/blob/70e9fa0a77aba91abd12d8d0023ce10e7bfe80a7/src/pages/settings/Preferences/PriorityModePage.js#L24-L26
We change to this:
const defaultProps = {
    isLoading: true,
    priorityMode: CONST.PRIORITY_MODE.DEFAULT,
};

At: https://github.com/Expensify/App/blob/70e9fa0a77aba91abd12d8d0023ce10e7bfe80a7/src/pages/settings/Preferences/PriorityModePage.js#L55-L59
We change to this:
    {props.isLoading ? (
                <FullscreenLoadingIndicator />
            ) : (
                <SelectionList
                    sections={[{data: priorityModes}]}
                    onSelectRow={updateMode}
                    initiallyFocusedOptionKey={_.find(priorityModes, (mode) => mode.isSelected).keyForList}
                />
            )}

At:
https://github.com/Expensify/App/blob/70e9fa0a77aba91abd12d8d0023ce10e7bfe80a7/src/pages/settings/Preferences/PriorityModePage.js#L70-L74
We change to this:
withOnyx({
        isLoading: {
            key: ONYXKEYS.IS_LOADING_APP,
        },
        priorityMode: {
            key: ONYXKEYS.NVP_PRIORITY_MODE,
        },
    }),

What alternative solutions did you explore? (Optional)
N/A

@fedirjh any thoughts on the proposals here?

@fedirjh why the solution I proposed doesn't make sense to you?
The solution I proposed is how it is done across all other sections of the app, l think it is more recommended because fix the issue to not show information before we fetch the right info from the back-end, and it will keep it consistent on how it is done across the whole app.
Address page:
https://github.com/Expensify/App/issues/27814#issuecomment-1739324832
Display Name page:
https://github.com/Expensify/App/issues/28077#issuecomment-1735956156

@fedirjh what is OP?

@kadiealexander What is the expected result when we initially open the priority mode preference page?
Should we display the default data until the server data is synced?
Should we display a loading indicator until the data is ready?
I am leaning toward the second option as it will prevent the interaction while the data is loading.

@fedirjh Agreed, I don't think we should show default data and have it be interactable if it's possibly going to change after it loads.

@hungvu193 Can you please link to what makes you say this?

Hmm wait isn't that a selected proposal should have both correct RCA and solution?

No, I am referring to your last message in the conversation -- this one -- what makes you think this?

@hungvu193 remind me that issue please

The root cause of the problem is that we currently don't display a loading while app data is still being fetched, that way the user can interact with the select list before the data is fetched from the backend.
My proposal is to add a loading screen.

This seems more like "solution" than "root cause"

Not overdue.

So what do we do here @fedirjh ?

Thank you for the summary. Re-reading the issue from the beginning I have these thoughts:

@lcsvcn about your proposal, won't the same problem exist in all other Right Hand Panes that make an API call whilst something else is loading...?

Can someone clarify for me why the optimistic data is not working in this case? If the API call is optimistic and we don't wait for the response before showing the expected result, then this bug would not exist, right?

@flodnv Yes, not to all, but in any right panel that allow user to interact with UI and edit options before data has finish loaded from the API, allowing concurrency to happen in some scenarios.
I currently reported other parts of that app that I was able to reproduce the same issue I reported here, like this issue:
https://github.com/Expensify/App/issues/29179
As I explained here, we currently have two different bugs in the same component, so we may want to address this in two separated issues to solve the component behavior and avoid compromising UX in bad networking conditions.

@hungvu193 well, I agree with you about the RCA in this issue, but if you take a look into the conversations (on slack too) there are two issues in the same component:

App should display correct priority mode on login and also maintain background highlight over correct value
No loading indication when loading App displays 'Most recent' causing in bug in slower networks

If you take a look into the attached the Slack conversation for the issue that I have reported, at the time they classify it as a duplicated, so I sent my proposal here. So after some discussion, an Expensify Engineer reviewed it to see if they would open two separated issues or fixes both with one issue. Seems like they opted to fix it with one single implementation.
So maybe just to be clear, we could open a new issue on GitHub with the report I have created and close this one, when the other bug is fixed we can mention it here, since it would be fixed automatically by the loading implementation. Just a suggestion, because right now there are two bugs in same component.

However the highlight background still stayed at PRIORITY_MODE.DEFAULT, the initiallyFocusedOptionKey was only calculated once in our first render because it's a state.

Hmm, but if we made this optimistic, and save it in Onyx (before the API call returns), then this problem would not exist, right...?

@fedirjh @hungvu193 I'm sorry, I'm having trouble following why optimistic data is not fixing this problem. Can you walk me through step by step as to why the optimistic data is not fixing this problem?

Got it, thanks. So that's why we think that some sort of loading indicator would at least let the user know that something is happening, and then won't be taken by surprise about this sudden unexpected change of data?

Okay, thanks for all the details. This is tangentially related to another problem I've been raising internally, so I will get back to that one whilst including these details, and then get back here with the outcome. I'll be in touch soon!

@flodnv any update on the outcome?

Finally got the time to post here: https://expensify.slack.com/archives/C04JD99283A/p1699366137184659?thread_ts=1696374112.724199&cid=C04JD99283A

Posted in #expensify-open-source here: https://expensify.slack.com/archives/C01GTK53T8Q/p1699972596342559

For now this is on HOLD for that proposal, which is being looked at here: https://expensify.slack.com/archives/C05RECHFBEW/p1700683134147369?thread_ts=1700580012.446519&cid=C05RECHFBEW

Still on hold.

I asked here if there's another GH we can follow: https://expensify.slack.com/archives/C05RECHFBEW/p1702645490391279?thread_ts=1700580012.446519&cid=C05RECHFBEW

Still on hold.

Internal planning issue is here: https://github.com/Expensify/Expensify/issues/350373

Internal issue may be picked up in the next couple of months with some luck.

Still on hold, not a priority at this time.

Same as above.

Same as above.

Still on hold.

Same as above.

@flodnv can we close this?

Hi @kadiealexander, @flodnv is this issue eligible for reporting bonus?

This is now on hold for https://github.com/Expensify/App/issues/46611

Still on hold.

Still holding for https://github.com/Expensify/App/issues/46611, we're getting closer.

@flodnv should we close based on this?


Copyedited the document

Read then delete

Make sure to use a concise title for the pull-request.
Use #patch, #minor #majora or #none in the pull-request title to bump the corresponding version. Otherwise, the patch version
will be bumped. More details

TL;DR
Please replace this text with a description of what this PR accomplishes.
Type

[ ] Bug Fix
[ ] Feature
[ ] Plugin
[x] Docs

Are all requirements met?

[ ] Code completed
[ ] Smoke tested
[ ] Unit tests added
[ ] Code documentation added
[ ] Any pending items have an associated Issue

Complete description
I fixed the documentation with punctuation error and verbal errors.
Tracking Issue
https://github.com/flyteorg/flyte/issues/
Follow-up issue
NA
OR
https://github.com/flyteorg/flyte/issues/

Hi, @Sayanta66! Is this a hacktoberfest-related PR?

I have to work on all of the docs? Or just this doc?

@samhita-alla Can I copy-edit on a doc by doc basis. Because that will be easy I guess? It will form a lot of PR but will break the work

I have to work on all of the docs? Or just this doc?

The whole flytectl docs, i.e., all pages under the flytectl repo. You can find all the pages here: https://docs.flyte.org/projects/flytectl/en/stable/. As mentioned in the issue, the docs should be very user-friendly—no typos, grammatical errors, etc. You can find the remaining requirements in the issue's comments.

And you can merge this PR or atleast Review it because it has fixed some problems. I will do all the docs today.

And you can merge this PR or atleast Review it because it has fixed some problems. I will do all the docs today.

Please create a PR for all the changes at once. That would be helpful.

Only issues will be merged or else it will not be merged, right?

Only issues will be merged or else it will not be merged, right?

No doc edits don't necessarily need an issue. Thank you for the help ❤

Also you have to sign off the commit as per linux foundation guidelines

@kumare3 and @samhita-alla I opened another big PR so closing this. Can you please review it? So that I will be able to complete coyediting of the rest.


simplify deprecated package requirements

This is a list of all requirements in the repo:
* `./visualization/requirements.txt`

* `./core/requirements.txt`

* `./core/requirements-ray.txt`

* `./io/requirements.txt`

* `./io/requirements-geodb.txt`

* `./io/requirements-meteoblue.txt`

* `./features/requirements.txt`

* `./mask/requirements.txt`

* `./ml_tools/requirements.txt`

* `./ml_tools/requirements-tdigest.txt`

* `./ml_tools/requirements-plotting.txt`

* `./coregistration/requirements.txt`

* `./geometry/requirements.txt`

some of these are not needed anymore (tdigest, meteoblue, geodb)

removing them would break existing scripts, invalidating the final release of subpackages IMO (though they are rarely used)


Azure platform optional prefix and logging level followup

Follow up to this Azure Platform Support.
Main changes are allowing the prefix to be set rather than hardcoded to "azure_", and lowering logging to a debug level so it doesn't create a warning when running discovery on a non-Azure platform.
[x] Configuration Infrastructure
[x] Does not have any changes that may affect Istio users.

@justinwei2: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio
e102b55175ef57da1b4b7b2804275cd220fcdeb0
link
/test unit-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@rshriram i believe this was one of the changes you previously requested (optional prefixing). would you mind taking a quick look?


HAPROXY and send-proxy parameter

We setup a simple test for maillin and everything looks fantastic so far except for a proxy test.
using one of the latest haproxy setups, we wanted to test proxying the node servers running mailin.
With the send-proxy command turned on for the server, mailin crashes instantly with the checks.
server smtp-work <IP_ADDRESS>:2525 check send-proxy
error: Error: write EPIPE
at Object.exports._errnoException (util.js:856:11)
at exports._exceptionWithHostPort (util.js:879:20)
at WriteWrap.afterWrite (net.js:763:14)
events.js:146
throw err;
^
Error: Uncaught, unspecified "error" event. ([object Object])
at emit (events.js:144:17)
Any ideas or thoughts?   We need to proxy the IP of the actual sender through the haproxy.
Thanks

@TimMeade I'm not familiar with haproxy in particular and tcp proxying in general. How does the send-proxy protocol forwards the sender IP?
Usually, EPIPE errors arise when the server on one end closes the connection. Would it be possible that haproxy closes the connection too early?


Bump Merlin Core dependency to 0.7.0

NVT now depends on executors, which only started being available in Core in 0.7.0. This dependency mismatch is causing not infrequent problems for users trying to install NVT.

@jperez999 It looks like this version didn't get bumped previously because there's no version of s3fs that depends on fsspec 2022.5.0:
    merlin-core 0.7.0 depends on fsspec==2022.5.0
    s3fs 2022.7.0 depends on fsspec==2022.7.0
    merlin-core 0.7.0 depends on fsspec==2022.5.0
    s3fs 2022.3.0 depends on fsspec==2022.3.0

Can we move forward from fsspec 2022.5.0 at this point?

Bumping the dependencies in Core seems to work, but I might be missing something about why we had fsspec pinned in the first place: https://github.com/NVIDIA-Merlin/core/pull/201


Mixr Rewrite

This PR is a complete rewrite of mixr from the ground up, aiming to improve single-threaded performance and usability.

The rewrite is not quite finished and is missing the buffer streaming that current mixr has, but the rewrite is so much better I'm going to merge this now.


Use WMTS tile matrix level set for WMS layers

WMS layers should use a level set based on a level-zero tile set consisting of two 180x180 tiles. This may allow server-side caching to excel as these tile requests may have already been made by other clients, or the cache may have been prepopulated to accomodate a WMTS tile scheme (ala GeoServer).

[x] EoxOpenStreetMapLayer
[x] EoxSentinal2CloudlessLayer
[x] EoxSentinal2WithLabelsLayer
[x] UsgsImageryTopoBaseMapLayer
[x] UsgsTopoBaseMapLayer

Configured layers to use EnhancedWmsLayer which uses a WMTS level-set instead of a WorldWind Java level set.
See commits dab0475b1 and d3ed704ba


Do not include dependencies with PrivateAssets="All" in the compiler package

FindNuspecReferences.ps1 adds all dependencies to Compiler.nuspec, even ones marked with PrivateAssets="All". That meant that the StyleCop analyzers for the Q# compiler source code were propagating to projects that have a reference to the Q# compiler package, which is a bit unwelcome for downstream projects.

It seems that PrivateAssets="All" implies that something is a development-only (i.e. build-time only) reference, and shouldn't be a package dependency:

https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#controlling-dependency-assets

https://github.com/NuGet/Home/issues/4125#issuecomment-280787267 referring to dotnet pack:

pack should not emit a dependency when <PrivateAssets>all</PrivateAssets> is specified

I just ran into this today. Thanks for fixing this, currently the compiler nuget package drags in Stylecop reference when installed and ruins the project's code analysis 😂 it would be good to release the new version out

Yes, sorry about that! I believe you can work around it for now by adding this .editorconfig to your project, which should disable all StyleCop rules...


Modal: fix tooltip TypeError on close

Fixes the error displayed when closing a modal with a tooltip that was never shown.
Closes: #31110

I wonder if we have more cases like this one?

I'm more concerned about listening to a modal hiding in our tooltip component, for me we shouldn't do that @XhmikosR

I'm more concerned about listening to a modal hiding in our tooltip component, for me we shouldn't do that @XhmikosR

Also, true. Does this code come from v4? You rewrote most of v5's JS code :)

Yep it comes from our v4

I'm more concerned about listening to a modal hiding in our tooltip component, for me we shouldn't do that @XhmikosR

It makes sense why it's there (if that's what you're questioning), since it's a bit awkward that if you open a popover/tooltip and then close the modal.
The popover/tooltip will be open the next time you open the modal.

That's the reason yes, but is it really a good thing ? IMO it should be handled by our users to delete their tooltip if needed

Perhaps.
I guess the current implementation limits it so they can't keep it open. Even if they wanted to.
While if the code was removed, it would keep it open, while still allowing the users to specifically close them if they wish.

Anyway you fix is good @Hiws but can you add a unit test please ?

Anyway you fix is good @Hiws but can you add a unit test please ?
@Johann-S

Tried writing this test for 2 hours, and it looks like it's working now.
However, I've never really written unit tests, so not sure if it's correct or not.

I think the test should be in modal not in tooltip :)

I think the test should be in modal not in tooltip :)

Ii feel like this case isn't specifically tied to modals, but the tooltip's hide method being run without the show method ever being ran.
Which is why i placed it under the tooltip tests and not modal.

The error your patch fixes is in modal.js so that's where it should be tested that we don't throw.

NVM, you are right, I need to sleep.

NVM, you are right, I need to sleep.

I'll take part of the blame for having a bad title 😉

just my last comment and we are good to gere here @Hiws thanks for your work 👍

Before merge, or alpha 2, use on child component style="pointer-events: none;"
<button class="btn btn-light" data-toggle="tooltip" data-placement="top" title="Tooltip on top">
    <svg width="18" height="18" style="pointer-events: none;" ><use xlink:href="#heart" /></svg>
</button>

Sorry for being out of the loop, what's the status of this one?

Pulling from Alpha 2 given unclear status.

We are waiting for @Hiws to do a last change and rebase his branch

Sorry for the delay.
I'm not quite sure what you mean with you should call it twice and except nothing.

You're right it was good like that thanks 👌


RFC 0036 and 0037: need to explain why payloads aren't shown

Per a discussion on the Aug 7 2019 community call...
The RFCs show messages, but omit detail about specific payloads (the actual content of credentials and presentations). The reason is deliberate (allow evolution of credential formats independent of the protocol that exchanges them). However, the RFCs don't explain this. We need verbiage in the RFCs to clarify.
We probably also need links in the RFCs to help people find the format of the payloads, even if the RFCs themselves don't show the data.

@llorllale @TelegramSam @kdenhartog

As shown in the issue title this affects both RFC 0036 and 0037 and we should delay the two week waiting period until this issue is resolved.

Did anyone volunteer for this one?  Glad to take it if not.  Grab it back from me if you volunteered.
@dhh1128 @kdenhartog

@dhh1128 @llorllale
Maybe I missed the point of this issue - I thought this was about the contents of the attachments and notably the Indy format.  In each of the message descriptions, there is a description of the contents of the attachment and a link to into the indy-sdk code to where the related call is defined, and the data structures are documented.
Is that not sufficient, are the links incorrect, or is the issue being raised for some other purpose?
Example:  request-presentation:

For Indy, the attachment contains data from libindy about the presentation request, base64 encoded. The following JSON is an example of the libindy-request-presentation-0 attachment content. For more information see the Libindy API. https://github.com/hyperledger/indy-sdk/blob/57dcdae74164d1c7aa06f2cccecaae121cefac25/libindy/src/api/anoncreds.rs#L1214

@swcurran the goal here is to explain why the RFC deliberately stops short of specifying the contents of the payloads and instead opts to leave it up to implementations.

I listened to the call and get the context better. What was throwing me off was saying this wasn't covered and the point about providing a connection to the implementation. That is called out in the already in the RFC, but I'll make it even more explicit.

Resolved by PR #173


How to use jsrender script template in angular 2 application?

I have tried jsrender script template  in angular 2 application
Its not working to me
Please suggestion to me
Regards,
Thangavel E

The issues data base is either for bug reports or for feature requests.
Also, it is not really possible to reply to your question since I have no idea what approach you tried to use for using JsRender templates, and what went wrong. In addition, I  am not an Angular expert, so cannot provide specific help on this at this point...


Deal with FF Corruption

@markmacgillivray we can't seem to find the file for this. cc @meganwaps

@markmacgillivray @JosephMcArthur any luck finding the FF code?

I talked to Steve about this. The latest firefox version was actually generated from the oab-chromeaddon, which was a port of the old code into a newer-ish chrome framework, but still with the old code inside it. So still the potential for errors from old code becoming invalid in there. The generated file must originally have been created by Steve and uploaded to the FF store by Joe (Steve says he had no access to the stores and just provided the files). However Steve no longer has the file.
@JosephMcArthur does this sound familiar to you, would you have such a file anywhere? If not I can generate a new one once I get the script (I think Steve has linked to it in the repo, just have to look - have not used that stuff yet.)

I think this is that file: https://www.dropbox.com/s/9azqwhmnka5hesy/odb_firefox_0.8.7.xpi?dl=0

@markmacgillivray @meganwaps any update on manually installing this? I'm told it's unsigned.

My suggestion here is that we write a quick note about this on the blog (@chealyse) and link that from the current Firefox button on account / download pages. Or, we can simply remove that button for now.

Presumably it is OK to close this, now we have two weeks to go until new version, and no fix for the old FF. The dev site just shows a msg saying new plugin coming soon.


Having trouble on calculating gradient of the network output w.r.t. input

Hello Haotian, thanks for this amazing library!
I'm currently working on a project with a need to calculate the gradient of the network output with respect to the network input explicitly. However, torch.autograd failed to do so and complaining mm(): functions with out=... arguments don't support automatic differentiation, but one of the arguments requires grad. I can't find anywhere in the library that calls torch.mm(out=...). Do you have any idea how this issue is caused? The following snippet can be used to reproduce this error.
import torch
import torchsparse
import torch.nn as nn
import torchsparse.nn as spnn
import numpy as np
from torchsparse import SparseTensor
from torchsparse.utils import sparse_quantize, sparse_collate_fn

def generate_random_point_cloud(size=100000, voxel_size=0.2):
    pc = np.random.randn(size, 4)
    pc[:, :3] = pc[:, :3] * 10
    rounded_pc = np.round(pc[:, :3] / voxel_size).astype(np.int32)
    labels = np.random.choice(10, size)
    inds, _, inverse_map = sparse_quantize(
        rounded_pc,
        pc,
        labels,
        return_index=True,
        return_invs=True
    )

    voxel_pc = rounded_pc[inds]
    voxel_feat = pc[inds]
    voxel_labels = labels[inds]

    sparse_tensor = SparseTensor(voxel_feat, voxel_pc)
    label_tensor = SparseTensor(voxel_labels, voxel_pc)

    feed_dict = {
        'lidar': sparse_tensor,
        'targets': label_tensor
    }

    return feed_dict

def generate_batched_random_point_clouds(
    size=10000,
    voxel_size=0.2,
    batch_size=2):
    batch = []
    for i in range(batch_size):
        batch.append(generate_random_point_cloud(size,
                                                 voxel_size))
    return sparse_collate_fn(batch)

device = 'cuda'

model = nn.Sequential(
    spnn.Conv3d(4, 32, kernel_size=3, stride=1),
    spnn.BatchNorm(32),
    spnn.ReLU(True),
).to(device)

feed_dict = generate_batched_random_point_clouds()
inputs = feed_dict['lidar'].to(device)
targets = feed_dict['targets'].F.to(device).long()
outputs = model(inputs)

coords = inputs.C.float()
sdf = outputs.F

coords = torch.autograd.Variable(coords, requires_grad=True)
grad = torch.autograd.grad(outputs=sdf, inputs=coords,
                           grad_outputs=torch.ones(sdf.size(), device=sdf.device),
                           create_graph=True, retain_graph=True, only_inputs=True)

Thanks a lot for your time!

Hi Jiaming,
Thanks for the question and sorry for the delayed response. I was preparing for an exam in the past two days. Regarding the error message from PyTorch, our library did use the torch::mm with out tensor specified here. I think this might partially explain the reason why you got this error.
For the code snippet you provided, I think it might be hard for you to get the gradient on the coordinates since they should not be in our computation graph. However, I do think getting the gradient for the input features is possible, if you run the following code:
model.train()

feed_dict = generate_batched_random_point_clouds()
inputs = feed_dict['lidar'].to(device)
inputs.F.requires_grad = True
targets = feed_dict['targets'].F.to(device).long()
outputs = model(inputs)

loss = outputs.F.sum()
loss.backward()
print(inputs.F.grad)

after the model definition (i.e. the line containing to(device)). Here I define loss = outputs.F.sum() to achieve grad_outputs = torch.ones(sdf.size(), device=sdf.device). Hope the code can help in your applications.
Best,
Haotian

Thanks for your reply!
I found that acquiring gradients with autograd.grad (instead of loss.backward()) requires torch.mm without out=... arguments. I attempted to change all torch::mm_out() calls in the C++ implementation to torch::mm() but the output of the network changed for some unknown reason. Since I've figured out another method to calculate the gradient without autograd, I will close this issue for now. Thanks for your help!

Hİ @JiamingSuen ,
What is your another method without autograd? Could you share it with me?
Thanks.


Error on update - replace unchanged value by last value modified

@Mewriick
1 - When i save a new value on a row,
2 - And then, i save another row without changing any value this time,
3 - The value that was changed in the first case replaced the unchanged value of the second one

public void ItemSavedOperationFinished(SaveResultArgs saveResultArgs)
    {
      bool res = false;
      TestDto newObj = (TestDto)saveResultArgs.Item;
      for (int i = 0; i < ForecastOld.Length; i++)
      {
        if (newObj.Code == ForecastOld[i].Code)
        {
          if (!newObj.IsEqual(ForecastOld[i]))
          {
            res = true;
            UpDate[newObj.Code] = DateTime.Now;
          }
          break;
        }
      }

@Methraen
New verison is released and this issue should be sovled


Fix entry types for pylint and pep8 checkers

Add postprocess function for pylint and pep8 makers to correctly set
entry types.

Since flake8 wraps pep8 and other tools, they could share the same post-process function.


Audio nog working

So when i first opened my game it asked me if i wanted to enable audio and i said yes. After closing it and opening it later my audio didnt work and it didnt ask me for it again. Still playing without audio

I've not seen this issue myself. Your iPhone needs to be unmuted for audio to work in Game Play. You might find it's useful to force quite the app and relaunch it.

We can re-open this issue if the problem persists.


Surface host health telemetry / logs

We have observed many failure modes where the host is crashing and restarting. These failures can occur due to platform bugs or from user error.  Regardless of the underlying cause, the biggest issue is that these failures are not easily visible from the functions portal. Sometimes they will appear as a red popup (e.g. if the error occurred on host startup) but in many cases the error is not surfaced at all. In these cases it is very difficult for the customer to discover that something is wrong and troubleshoot it.
We know that the platform captures the necessary data to determine that there is a problem. We have telemetry for when w3wp is crashing. Script host level errors are captured in the host logs (as long as the functions portal is open - this is a separate issue that requires further consideration i.e. should host errors be logged to the storage account?). We need to turn this data into a useful feature that prompts the user to investigate further.

@paulbatum to discuss with @christopheranderson on a design for how to surface this information.

Most likely to be addressed by https://github.com/Azure/azure-webjobs-sdk-script/issues/727

I don't see how this is addressed by https://github.com/Azure/azure-webjobs-sdk-script/issues/727? In the portal we give you immediate function level logs, but we don't show host level logs that we have. I believe we had some other issues related to showing this in the portal in the same way we show function logs.

Blocked on https://github.com/Azure/azure-webjobs-sdk-script/issues/1301

this is already fixed

Can you elaborate? You're saying I can now see my host logs in the portal? I just tried, by making my host.json file unparsable. Where can I see the error?
ScaleController is now also sending us error logs and we pump those into the host logs. Ideally we'd provide a way for users to see those in the portal.

oh is that what this issue is about. We just clicked on the last link above (https://github.com/Azure/azure-functions-host/issues/1301) and it seemed that it was about compile errors so we closed this issue.
If this is about surfacing non-function errors then @btardif  we'll need a design for that, where that will go, how it shows up, etc

clearing dev assignee until there is a design.

@paulbatum this item is almost 2 years old, is it still relevant?
I plan on closing this by the end of s98 unless I hear otherwise.


Kim mb 4125 selectable card component

Description
Creates a SelectableCard component for a radio and adds it to storybook.  Three states are displayed in storybook: unselected, selected, and disabled.
Reviewer Notes
I did not create a checkbox option or separate component.  it sounded like it may not be necessary (see thread) right now.
Setup
make storybook
Look under Customer Components --> SelectableCard
Code Review Verification Steps

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, IE, Edge).
[ ] User facing changes have been reviewed by design.
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change.

Screenshots
phone view:

browser view:

selected:

disabled:

The only other thing I am noticing this that the icon in the top left corner is missing, but it seems that icon has not been added to the repo for use (if it were, you would find it here: https://storybook.dp3.us/?path=/story/global-icons--all) I will export it out of the Sketch file and get it added for you ASAP!

Since we're not implementing the actual handler for this icon in this story, it seems like it would make more sense to add the icon itself when we do add the tooltip/modal?

This is great! I am noticing is the drop shadow is missing when the card is selected. I've spent some time this morning to see if there was a css-only way to achieve this, but I think we need to add a class/id to the .cardContainer div in order to have a way to target the div when the radio is selected. when we have a way to target it, we should be able to add the shadow with @include u-shadow(2);
The only other thing I am noticing this that the icon in the top left corner is missing, but it seems that icon has not been added to the repo for use (if it were, you would find it here: https://storybook.dp3.us/?path=/story/global-icons--all) I will export it out of the Sketch file and get it added for you ASAP!

oof- you're right- I totally forgot about the color change and didn't see the drop shadow when selected.  Will work on that.
Do you mean to informational icon in the top right?  The story specifically says not to worry about that- we will cover it when we build the modal in another story.

Warnings

:warning:
Please add the JIRA issue key to the PR title (e.g. MB-123)

  Generated by :no_entry_sign: dangerJS against 50c37b55e56a84584fc78f83882ad46f3d1135c8


wire up user stats to UI

Update UI to integrate with new augur-node endpoint to get user time ranged stats.
augur-node tix is https://github.com/AugurProject/augur/issues/1277

moving to augur repo


build error for cross arm-linux-gcc

Scanning dependencies of target arch
[  0%] Building C object common/log/arch/linux/CMakeFiles/arch.dir/arch.c.o
clang: warning: -lpthread: 'linker' input unused [-Wunused-command-line-argument]
clang: warning: -lpthread: 'linker' input unused [-Wunused-command-line-argument]
[  1%] Linking C shared library ../../../../lib/libarch.so
ld: unknown option: -soname
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [lib/libarch.so] Error 1
make[1]: *** [common/log/arch/linux/CMakeFiles/arch.dir/all] Error 2
make: *** [all] Error 2

I've solved this problem by commenting out the following in CMakefiles.txt
# set(CMAKE_C_COMPILER "gcc")
# set(CMAKE_CXX_COMPILER "g++")


update a bunch of test requirements

What does this pull request do?
Bumps some requirements for tests, in the hope that it fixes
an issue on Python 3.8.2

I'll wait with merging until we removed 3.4 from the test matrix. I'll open a PR to do that tomorrow.

merged into #745


Add warning about extreme path length limit on Windows

This is a very surprising gotcha and kind of a pain to have to regenerate & recompile your project if you didn't know about it. Which you definitely didn't.

Actually cancel this. It's literally impossible to have a short enough path on Windows so you cannot use this project on Windows at all.

This is already documented in https://docs.esp-rs.org/book/troubleshooting/index.html#long-path-names.

Actually cancel this. It's literally impossible to have a short enough path on Windows so you cannot use this project on Windows at all.

A lot of people use Windows for esp-rs projects, so its possible to workaround this issue.

Shouldn't the Troubleshooting section be for issues that might occur? This issue is going to be hit by every Windows user (unless they're extremely lucky) so it makes sense to tell them about it up front rather than let them hit it and have to search for the solution.
However, the check is actually not quite right so it probably makes sense to fix it before updating the documentation. See https://github.com/esp-rs/esp-idf-sys/issues/293

Shouldn't the Troubleshooting section be for issues that might occur?

This is not a problem for WSL users, which may windows users opt to use. So not all windows users are affected.
Making a reference to it early on in the book would be a good idea though, would you mind updating your PR?

Hi, sorry for the delay, I'm just coming back to this.

Making a reference to it early on in the book would be a good idea though, would you mind updating your PR?

Might have forgotten the context but I think that's what this PR does already?


feat(ContinuousFunctionalCalculus): show that the non-unital CFC commutes with integration

This PR shows that cfcₙ (fun r => ∫ x, f x r ∂μ) a = ∫ x, cfcₙ(f x) a ∂μ under appropriate conditions.
Note that #16013 (already merged) showed the corresponding result for the unital CFC.

bors r+


[$500] Thread - The cursor is not focused when opening a previously created thread.

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: v1.3.96-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause-Internal Team
Slack conversation: @
Action Performed:

Go to https://staging.new.expensify.com/
Log in with any account.
Navigate to 1:1 conversation.
Start a thread in owned message.
Go back and open the thread link.

Expected Result:
Cursor is focused.
Actual Result:
The cursor is not focused when opening a previously created thread.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Native
[x] Android: mWeb Chrome
[x] iOS: Native
[x] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/115492554/6eb62b1b-8c05-40d7-ac43-c26bcff49d25

View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01f0a8339a7396a1b3
Upwork Job ID:<PHONE_NUMBER>009238016
Last Price Increase: 2023-11-07

Proposal
Please re-state the problem that we are trying to solve in this issue.
The cursor not auto focused when opening previously created thread
What is the root cause of that problem?
IT is because autoFocus prop passed to Composer is false if it is not empty chat
https://github.com/Expensify/App/blob/a1a0f3897995a0992f38a885412af723174c7be2/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.js#L129
What changes do you think we should make in order to solve the problem?

We should focus before navigate to child report here
https://github.com/Expensify/App/blob/a1a0f3897995a0992f38a885412af723174c7be2/src/pages/home/report/ReportActionItemThread.js#L46-L48
What alternative solutions did you explore? (Optional)

This looks like an intentional behavior. We don't auto focus on mobile devices
if we still want to focus, we need to have discussions and set clear expectation, I think
cc @allroundexperts @lschurr

Proposal
Please re-state the problem that we are trying to solve in this issue.

Thread - The cursor is not focused when opening a previously created thread

What is the root cause of that problem?

Currently, we use the variable shouldAutoFocus to know should we auto-focus on the composer or not:
https://github.com/Expensify/App/blob/c2e40423ac71fa67e65b570342c39e4c2b25a46f/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions/ComposerWithSuggestions.js#L128
With the mobile device, we will auto-focus in case isEmptyChat and !ReportActionsUtils.isTransactionThread(parentAction), so in case of this bug, the thread report is not focused automatically.

What changes do you think we should make in order to solve the problem?

We can update the shouldAutoFocus to:

const shouldAutoFocus = !modal.isVisible && (shouldFocusInputOnScreenFocus || (isEmptyChat && !ReportActionsUtils.isTransactionThread(parentAction) || ReportUtils.isThread(report))) && shouldShowComposeInput;

What alternative solutions did you explore? (Optional)

NA

@allroundexperts could you review?

Let's go ahead and close. Thanks!


Request for internal facing ELB example

Is there any gists that the community can share with internal facing ELB's?

@BardiaAfshin I think your best bet for these sorts of questions is to share them with the group at:
https://groups.google.com/forum/#!forum/cloudtools-dev


continuous integration and status in readme

Provide basic continuous integration similar to glbinding.

I am still not sure if the yml-files are correctly configured. But I consider this issue done.


Formatting validation errors

I realize the validation errors are coming from Schema, but is there any way to further customize or improve upon this?
const LoginBody = S.Struct({
  name: S.String,
  password: S.String.pipe(S.minLength(5, {
    message: () => 'My custom message'
  }))
})

Error message:
{
    "error": "Request validation error",
    "location": "body",
    "message": "{ readonly name: string; readonly password: a string at least 5 character(s) long }\n└─ [\"password\"]\n   └─ My custom message"
}

Preferred:
{
    "error": "Request validation error",
    "location": "body",
    "message": {
         "password": "My custom message"
    }
}

The logic that I want is mostly implemented In the react-hook-form/resolvers effect logic
One way to allow this is if ServerRequestParser could be a service that I could implement and then provide?
Or perhaps better: an ErrorFormatter service or function?

The Schema error message is great for a programmer, but that's not a shippable error message for a public API

I used to have a pluggable schema error formatter in the past but I got rid of it. I'll take a look and possibly reintroduce it.


Pandas or NumPy frontend for Mimir

Add a NumPy/Pandas Dataframe wrapper for Mimir (load dataframe from Mimir, write dataframe back to Mimir)
Needed to support https://github.com/VizierDB/web-ui/issues/91

We need to be careful to preserve rowids correctly when we pass them into and out of Mimir

Evaluation metrics:

Degree of compatibility with Pandas/NumPy API (what functions are/are not supported)
Performance relative to copying data from Mimir to Python.
Performance relative to writing an equivalent SQL query.


Increment version for healthinsights releases

Increment package version after release of Azure.Health.Insights.RadiologyInsights

API change check
API changes are not detected in this pull request.

This does not look right.  The change log appears to be malformed due to having multiple entries for v1.0.0.    This will require manual intervention.
//cc: @koen-mertens, @tomsft, @asaflevi-ms


[v15 ictest] PFM Router

Builds off the 47 branch. Merge after 47-upgrade merges
Test from Noble Chain via the Strangelove Team. All credit goes to them (Dan, Justin, Andrew, & Jack)
Preview is just https://github.com/CosmosContracts/juno/pull/679/commits/25f417078585cc617dced3e23c3e9b211feebc49
files of importance

interchaintest/module_pfm_test.go

Going to do in another PR so it is cleaner into main


Evidence code filter

Hi,
As I mentioned to you at the meeting, the evidence codes in the filter (in the left side navigation bar) are hard to read and also the right side table doesn't match the codes on the left. Can you please add the three letter acronyms to the left side navigation bar?
Thanks,
Rama

The need for this is largely circumvented by #308