Rename parts with emailAdressto emailAddress

Situation
Accidently we used emailAdress instead of emailAddress at some locations
Wanted
We want that fixed and the typo removed.
Solution

[ ]  create new flyway script which renames the column in table ADM_USER_SELFREGISTRATION
(but don't forget to revert in undo script to wrong name again!)
[ ] rename  Signup.javafield and setter/getters
[ ] update admin script sechub-api.sh inside developer tools project so created json is using emailAddress
[ ] check for wrong spelling inside other code parts and fix there as well
[ ] check for wrong spelling inside documentation parts and fix there as well
[ ] update rest doc tests
[ ] fix failing tests
[ ] check DAUI (developer admin UI) works as expected

@de-jcup
Assign me to this issue please.

@zigfridus I assigned you.

@zigfridus sadly, the answer is: it depends.
If you have not done a lot of work on it, then in this case maybe the easiest way is to start over. The problem is, that if you rename fields, methods etc. you change a lot of files just a bit. Keeping track of what you changed might be difficult.
Another relative straight forward approach is to create a patch file containing only the changes you did for this issue. Copy the patch file into some directory not tracked by git (e.g. home folder). Next, checkout the develop branch again (don't forget to sync your fork), create a new branch (name it similarly e.g. feature-1139-rename…, but not exactly the same) and apply your patch.
I hope, my response provides you with some ideas on how to solve it. Feel free to ask in case you have additional questions.

@Jeeppler
Thank your answer. The problem is my develop branch synced with a origin also shows an error on build in system-tests.
I can't explain that. And I confused where can I get not broken sources for the new branch.

@zigfridus from my perspective this is what you can do:

push your current state to github (branch in your fork), so that I can have a look at it
paste the error message you get into this issue (helps me to pin down the problem)

@Jeeppler
It seems to me I found the source of my problem. It was in the cache.
I cleaned it with
sechub/sechub-developertools/scripts/sdc.sh -c
and then rebuild the source. Now the problem is gone.
I appreciate your assistance.

@zigfridus awesome, that you found the culprit 👍 . Finding out caching is the problem is always a challenge.

@Jeeppler @de-jcup
I would like to do a pull request for this issue. Could you please write which branch here I should use: develop or community?

@zigfridus community. Going forward we want all pull-requests from the community to the community branch. People listed in the MAINTAINERS.md will still push into develop.


Add Battery stock management

Checklist

[X] I have filled out the template to the best of my ability.
[X] This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
[X] This issue is not a duplicate feature request of previous feature requests.

Is your feature request related to a problem? Please describe.
No more fresh batteries
Describe the solution you'd like
An interesting function would be the management of the stock of the different stacks of the network with a decrease each time we press PRESS of an entity when we change the stack.
This could be used to launch a callback when there are less than X stacks left.
Thanks for the current integration, which is already a fabulous piece of work.
Describe alternatives you've considered
None
Additional context
None

This is something I've thought about a bit and has been discussed in the past.
This would be a long term improvement, I'll move it into the discussions area so not forgotten and hopefully we'll get some more feedback on what might be wanted on this.


Fix broken links to finders in README

Pulled from https://github.com/alphagov/specialist-publisher/pull/668

Thanks Elliot, and Russell!


profile.yml does not exist

I have run populate.py multiple times, each time it says
Writing to Profile...Done
However, when I try to access the file by doing
sudo nano ~/.jasper/profile.yml
I am shown a blank file.
Similarly, using
'touch ~/.jasper/profile.yml`
Fails with "No such file or directory"

try find / -name 'profile.yml' and see where the file is?
If it really isn't being created then you should run populate.py --debug and see what it says


complex functions acting strange

When I try to run a complex transformation, it runs fine, unless the function has a pole. I would like if someone could tell me what I could do to fix this. Thanks in advance.
Code:

Middle:

Last frame:

Can you show me how you get complex Transformation of the whole coordinate plane for any Function?

I'm A little late but you change the lambda function in CONFIG to whatever you want.

But I don't understand why you use self.apply_complex_function(self.function)
Why not self.apply_complex_function(zeta)?

Hi, were you able to solve this problem? I'm having the same problem myself right not, wondering if there's some way to fix it. Thank you

sadly no. I wish though lol

Right now I'm trying to check the [discontinuity fix code](https://github.com/3b1b/manim/pull/832), but I'm having some trouble understanding how to use it.

After several days I managed to solve the problem with the current version of manim
#1169
#1170
#1171

After several days I managed to solve the problem with the current version of manim
#1169
#1170
#1171

Could you please post the code you used for this specific animation? Just to see how your method is applied in context? Thank you

After several days I managed to solve the problem with the current version of manim
#1169
#1170
#1171

This works fine for the zeta Transformation of complete plane but it doesn't work for the transformation of half plane. It is showing something like this:

Check my code #1169
class TestZetaOnHalfPlane(ZetaTransformationScene):
CONFIG = {
"anchor_density" : 15,
}
def construct(self):
self.add_transformable_plane()
    prueba = self.get_dense_grid()

    self.plane.submobjects = [prueba]

    self.apply_zeta_function()
    texto = TextMobject("yinjann")
    texto.scale(0.8)
    texto.to_corner(DOWN + RIGHT)

    self.play(Write(texto))

    self.wait(3)

Check my code #1169
class TestZetaOnHalfPlane(ZetaTransformationScene):
CONFIG = {
"anchor_density" : 15,
}
def construct(self):
self.add_transformable_plane()
prueba = self.get_dense_grid()
self.plane.submobjects = [prueba]
self.apply_zeta_function()
texto = TextMobject("yinjann")
texto.scale(0.8)
texto.to_corner(DOWN + RIGHT)
self.play(Write(texto))
self.wait(3)

Not completely related, but - how were you able to define your function on only half of the plane? I want to make animations of functions acting on the upper half plane


New enchants

Champion X
Hecatomb X
https://hypixel.net/threads/august-5-chili-pepper-update.5057174/

most likely would be same data as stuff like expertise yes?

most likely would be same data as stuff like expertise yes?

Yes

added with #1629

Still needs to be added to the max enchants array


Introduce a maximum time to live property

In order to restrict the tokens which have a very long time span

Closing for now, we have a project specific property but I'm not sure the case is strong enough to have a standard property around it; if someone disagrees then please reopen


Integration with Sense AWS. Fabric slice expiring fails to to delete OESS connection.

When the FABRIC slice expires, it will fail to delete the OESS connection which depends on the deletion of the AWS direct connect VPC attachment.  This OESS connection might be incorrectly reused by subsequent workflows using the same workflow name.
NOTE: Calling fabfed workflow destroy will only delete the sense portion if the FABRIC slice has expired.

Potential features design:

immediately renew the FABRIC slice to last longer.
Develop a -renew operation for the workflow session.
Register with a provider (or 3rd party) notification service (email / text / slack etc.) to remind users to renew or destroy the workflow before the expiry.

@abessiari Let's use fablib slice.renew() call to extend a FABRIC slice life time to 14 days. This should buy us time to clean up most of workflows.
https://github.com/fabric-testbed/fabrictestbed-extensions/blob/e716c26b0aa8d04a8103922bb892500329f22c2d/fabrictestbed_extensions/fablib/slice.py#L1409
14 days is the default max number of days for renewal. With Slice.NoLimitLifetime permission tag on a project, we can do up to 26 weeks.


fix: float amounts validation in SatAmount type

let's merge this one @dolcalmi. could be good to have an alert also


FeignContext add method getSuitableInstance to get instance with eurekaServiceName and classType

for the issue https://github.com/spring-cloud/spring-cloud-netflix/issues/2763 ,
do get bean from context could with eurekaServiceName and beanType.
/**
 * getSuitableInstance from context
 *
 * 1.without bean for the type return null
 * 2.only exist one return the bean
 * 3.choose the one which has @Primary annotation
 * 4.choose the one which name is FeignProducerName+type.getSimpleName
 * 5.on enough info for choose from multiple bean ,return null
 * @param name
 * @param type
 * @param <T>
 * @return
 */
public <T> T getSuitableInstance(String name, Class<T> type)

@abnerbos Please sign the Contributor License Agreement!
Click here to manually synchronize the status of this Pull Request.
See the FAQ for frequently asked questions.

@abnerbos Thank you for signing the Contributor License Agreement!

This is the wrong approach. You should put decoders on specific configurations per feign client.

The problem has been solved because each feign client Encoder/Decoder is in web auto scan path, so while other feign client use the type get  Encoder/Decoder  will get wrong, thank you for your answer.
And this solution really not elegant, but confused me is the way obtain the bean, maybe in the parent context, maybe in other feign client default config or each feign own config, It would be better if there was a clearer way.


feat: implement 0x48 - BASEFEE

Since
London
Group
Block Information
Description
0x48 - BASEFEE
Index 1 is top of the stack. See PUSH.Stack outputbaseFee: base fee in wei.Example
| Input | Output
-- | -- | --
1 |   | 10
Reproduce in playground.Error casesThe state changes done by the current context are reverted in those cases:Not enough gas.Stack overflow.

Done


Optionally use of helm3 instead of helm2

I'd like to use helm3 for managing a new hub. The hubploy dockerfile just installs helm 2.14.3, but has a note about multiple versions specified at runtime.
https://github.com/yuvipanda/hubploy/blob/master/Dockerfile#L23
Happy to follow up with a PR, but need a bit of guidance first. Perhaps this would also require a new file hubploy/helm3.py to account for potential syntax differences with helm3 commands?

I might be missing the point, but I believe that you can already use helm3. See this deployment: https://github.com/learning-2-learn/l2lhub-deployment/blob/staging/.github/workflows/deploy.yaml. However, note the somewhat iffy use of the dev image.

The only thing helm3 seems to need extra is namespace creation inside hubploy. We might want to do this regardless anyway if the namespace does not exist. We will then have to ship multiple versions of helm in the image, and pick one based on the version of helm installed in the cluster.

@yuvipanda - would it be unreasonable to scrap helm2 altogether and require helm>3 going forward ?

@scottyhq hmm, maybe we can switch the default to helm3 instead? They are mostly backwards compatible...

It is my understanding that hubploy's master now use a binary named helm, and that everything will work if that is a helm2 or helm3 binary. Could this be correct?

@consideRatio it defaults to that, but you can override it by setting a HELM_EXECUTABLE environment variable

Oh, to me this sounds very good then, and this issue would make sense to close with the summary:

hubploy can work with a configurable helm binary (HELM_EXECUTABLE), but defaults to work with on called helm.
hubploy will will make the right call on how to work with chosen binary depending on if it is a helm 2 or helm 3 binary
hubploy's Dockerimage ships with helm2 available in the helm binary, and helm3 available in the helm3 binary. So to use helm3 from the dockerfile, setting HELM_EXECUTABLE=helm3 is needed.

Since the original post is with support of HELM_EXECUTABLE added here, and by ensuring that we avoid breaking helm2/3 differences as added here, I'll close this issue!
Excellent work resolving this @yuvipanda! :heart:


Add info to docs about tile coordinates

A support ticket came in where the user was trying to get a tile by passing decimal degrees, instead of tile coordinates.
We should clarify that the the {x}/{y} is a tile coordinate. Currently, it looks pretty much the same as the standard decimal degrees format. Need to tell people that tile coordinates are used and provide instructions for teaching people how to convert
@kkowalsky knows of some resources that we can add to docs.

We should make the same change in the vector tile documentation.

💪

thanks. I was pulling the coords from id editor in osm thinking they would be the same.  I appreciate the clarification!


⚠ Bofrost.be has degraded performance

In d219797, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1348 ms

Resolved: Bofrost.be performance has improved in a26992d.


Changing theme is not possible :(

I'm using arch linux and I want to install the Forest theme. I followed the instructions and when i3 restart, I have an error. It tell me that client.focused or client.unfocused aren't allowed.

Stavros, can you check your e-mail please?

Good evening @Lrtcfr could you please post your i3 configuration file? I might be able to help you.
@karambaq Yes sir, I will reply to your e-mail as soon as possible.

@unix121 The above error appears after every login. No change in case after using i3 config from both Ice and Forest themes. But, resumes to work properly after executing ./i3wmthemer -t Ice from the scripts folder and, the same error appears after log out and log in.


inclusion of terraform test results in Coverage Docs

Adds the terraform test results to the Coverage Docs table to indicate that an operation was run using terraform.

Adapted the workflow to download artifacts from localstack-terraform-test project
Added new column to the table

TODO:

[x] run workflow with artifacts from feature branch
[x] change workflow to use main branch
- tested workflow, resulting PR https://github.com/localstack/docs/pull/571 and preview can be checked here: https://localstack-docs-preview-pr-571.surge.sh/references/coverage/coverage_sqs/

Please check the preview from here: https://localstack-docs-preview-pr-571.surge.sh/references/coverage (resulting from manual workflow execution using this branch).
We will run the workflow against main once we merged this PR.


Intended workflow

Hi,
I want to add prebuild to my node addon and I want to ask if I get the workflow right. If i have a new release ready:

Create Github release with changelog etc.
Prebuild the release on all platforms for all ABI versions
Trigger upload on all platforms to add the release downloads
Add release to npm

Does prebuild differentiate between armv6 and armv7?
Best regards

Hi,
I want to add prebuild to my node addon and I want to ask if I get the workflow right.

Hi! Cool :)
Not sure if you meant the pointed list as the workflow of prebuild or your own workflow, please excuse me if I got that wrong.

Create Github release with changelog etc.

prebuild will create the release on github for you, so need to do that manually. However, there's no support for adding a changelog (at least not yet, haven't thought about if we want to do that or not) so you would have to do that yourself manually (or using the github api I guess).

Trigger upload on all platforms to add the release downloads

This is also handled by prebuild after the binaries have been built.

Add release to npm

This is not handled by prebuild so something you have to do with npm publish, which also makes sense since you want to be sure the binaries have been built and uploaded to the release on github before you actually publish the new version of your module.

Does prebuild differentiate between armv6 and armv7?

This is a good question and something that is a bit of an uncharted territory. When I build for leveldown (using the rpi2) it will generate binaries of the form leveldown-v1.4.4-node-v11-linux-arm.tar.gz (see https://github.com/Level/leveldown/releases/tag/v1.4.4) and this is because node's process.arch returns the string arm, so it seems node itself doesn't handle that difference.

Ps. I would suggest you just tried and if the arm differences doesn't play out well for you, we'll adjust prebuild until it does.

Thanks for the fast response and you got it right. I read that prebuild will build and upload the binaries for me and that it obviously does not npm publish :) I think I was uncertain about the right use.

...so it seems node itself doesn't handle that difference.
That's right, but node binaries are available for v6, v7 and v8. Maybe performance aspects (instruction sets)?

Although armv8 is backwards compatible to armv5 I think it could be a good addition to differentiate between arm versions, because if I prebuild on armv7 it won't run on armv8 but prebuild will download the arm build. Or is ARM also upwards compatible? I'm not an expert in these things ;)
I think I will use the current solution until somebody cries (unlikely).

@mathiask88 Closing this if you don't mind :)


Add HPKP dynamic updates to proxy server

If there is "public-key-pins" header in HTTP request, verifier should be notified about that:
void AGCertificateVerifier::updateHPKPInfo(
        const std::string &dnsName, STACK_OF(X509) *certChain,
        const std::string &httpHeaderName, const std::string &httpHeaderValue);

HPKP will be dropped in next Chrome Canary.


Make it easier to build against custom osrm-backend

What Changed

centralizes osrm-backend version variable in package.json
documents how to build against:

a custom osrm-backend version via mason (for portable binaries)
or an existing local osrm-backend clone that has already been installed (to iterate fast)

So, no longer do you change the OSRM_RELEASE variable in the .travis.yml. Now, instead you change the osrm_release variable inside of the package.json.
The idea here is to:

Have the osrm_release variable just in one place (./bootstrap.sh now pulls from package.json)
Avoid using ENV variables and bash source which is easy to make mistakes with
Make it easier in branch diffs to see the relationship of osrm-backend version and node-osrm by storing their versions in the same spot.

GOCHAS

If you have the osrm-backend tools on your PATH, they will be used instead of the ones built locally. So, if you are just doing node-osrm development make sure to clean up any stale osrm-backend installs you might have.

Background
Currently to install node-osrm from binaries you run: npm install.
To install from source you type make. And to run the tests after a source build: make test.
These things will stay the same and they default to building against the osrm-backend develop branch.
However when doing development against custom branches of OSRM_BACKEND there were a variety of easy pitfalls.
This branch makes it easier, and documented, how you should:

Build against a custom OSRM branch, tag, or gitsha using mason + an automated source build of osrm-backend (done via the ./bootstrap.sh script)
Build against a local osrm-backend clone that you've been doing development in

Both these methods are documented in the readme in this pull.

All green now https://travis-ci.org/Project-OSRM/node-osrm/builds/112922109. After merging I will rebase this into the live branches that are pointed at osrm-backend branches which are based on osrm-backend develop.


Add PhaseId

Add PhaseId as ValueObject

Coverage remained the same at 100.0% when pulling 6a36f88f4372e44f70cc6fa24e085f644d911538 on add-phase-id into 54ce11b38f40eaa2dd6979da3a48ddbd04177cde on develop.

LGTM

Coverage remained the same at 100.0% when pulling 3c85d2aea40dc8a39bdf7f9cc5cfa49085dfe6b7 on add-phase-id into 81102a998f36899fe5d89f808f25804b53c3385e on develop.

Coverage remained the same at 100.0% when pulling a07888d31c83f52d95cce380e5916e6069966ac4 on add-phase-id into 0e2de7a0d399df6ff425706aac62f8071a4897af on develop.


Can't figure out how to rotate a box

Love your library and am using it quite a lot. I am having an issue rotating a box. What am I doing wrong? I have tried many things. I basically need the box to orient using the three points.
            g.Point3d centerPoint = new g.Point3d(17.2489, 19.8042, -0.307304);
            g.Point3d rightWing = new g.Point3d(17.7258, 19.7956, -0.303844);
            g.Point3d rearward = new g.Point3d(17.26, 19.8038, -0.289645);
            g.Box3d box = new g.Box3d(centerPoint, 0.05, 0.02, 0.01);
            g.Coord3d coord = new g.Coord3d(centerPoint, rightWing, rearward);
            g.Rotation rot = box.Orientation.ConvertTo(coord);
            box = box.Rotate(rot, box.Center);

I think the most confusing line is this:
g.Rotation rot = box.Orientation.ConvertTo(coord);
Let's analyse what happens there step by step:

box - you have defined your box in global coordinate system, therefore it is axis aligned box and it's orientation equals to zero rotation.

box.Orientation - this returns rotation object, which equals to the rotation needed to convert axis aligned box to your box (not including center point translation, of course). But since your box is already axis aligned, this operation will return zero rotation object.

box.Orientation.ConvertTo(coord) - this converts rotation object, obtained in previous step, to local coordinate system. However, the way GeometRi works, once you have created rotation, it will represent rotation action in 3D space, not matter what local CS you use. ConvertTo method changes internal representation of the rotation object, namely its rotation matrix stored inside (and you may get out this converted rotation matrix). But together with rotation matrix object stores reference coordinate system, and the final action will be the same. In your case the result of this operation still will be zero rotation.

There are number of ways to accomplish what you need. For example:
            g.Box3d box2 = new g.Box3d(centerPoint, 0.05, 0.02, 0.01);             g.Rotation rot2 = new g.Rotation(coord);             box2 = box2.Rotate(rot2, box2.Center);
Here you define box in global CS, then create rotation object from global to local CS and then rotate your box. But you can do in one line, directly defining your box in local CS:
g.Box3d box3 = new g.Box3d(centerPoint, 0.05, 0.02, 0.01, coord);

Perfect! Thank you again.


Always getting total = 0 when making a UtilsApi query

I'm using v2.0.3. I have a query like this:
const result = await utilsApi.sql(`
    SELECT *
    FROM idx_media_ref
    WHERE match('*${searchTitle}*')
    ORDER BY weight() DESC, ${orderByColumnName} ${orderByDirection}
    LIMIT ${skip},${take}
    OPTION ranker=expr('sum(lcs*user_weight)');

And I want to know how many rows matched this query, but the `total` value in the response is always equal to 0.

Example response:

result {
columns: [
{ id: [Object] },
{ podverse_id: [Object] },
{ title: [Object] },
{ created_date: [Object] }
],
data: [
{
id: 103,
podverse_id: 'fR1ISSE2_w',
title: 'Another soundbite title',
created_date:<PHONE_NUMBER>
}
],
total: 0,
error: '',
warning: ''
}

Is there something I need to add to the query to get the # of matching rows as the total? Or is this a limitation of manticoresearch-javascript?

➤ Nick Sergeev commented:
No, the query is ok. This problem did exist in Manticore 4.2.0, irrespective of client.  It's fixed now in 4.2.1 (dev version) so you can use it to avoid the issue.


"continuous compliance monitoring". What compliance standard is Pacbot using?

❔ "continuous compliance monitoring". What compliance standard is Pacbot using?
it mentions about "continuous compliance monitoring". What compliance standard is pacbot using? and if we established some compliance rule in AWS Config so How does Pacbot work together with AWS Config?
Also what compliance standard we are using for "continuous compliance monitoring".

We continuously monitor cloud through the policies enforced and provide a custom score which indicates how compliant you are with the rules PacBot enforced.
We are not currently supporting AWS Config Rules to gauge the compliance.


Django 4.0 compat

Replace .is_ajax() for HTTP_X_REQUESTED_WITH header validation (deprecated on Django 3.1)
Replace ugettext_lazy for gettext_lazy (deprecated on Django 4.0)
Replace url for path and re_path on urls.py
Add python 3.9 + Django 4.0 on travis
My name was showing up twice on Authors so I removed one.

@bmihelac, should I amend my PR to include Python 2 + Django <=1.9 or is it time to drop its support? What do you say?

thanks for taking the time to contribute this improvement @MrCordeiro
I see that you added pyproject.toml - there are some fields missing, like authors and description and version is "0.1.0". Is this by accident?
I agree to drop Python2 (this should be added to readme and changelog). Regarding Django, we can drop Django < 2.2 - Django 2.2 is supported until April, 2022.

Ah! That was an accident! I have the habit of using poetry to install the requirements/create the venv, but I shouldn't have committed it (plus, this project doesn't need one).
I'll fix that and add the other changes, thanks!

@bmihelac, as these are breaking changes, should I upgrade the version to 1.0.0 instead of 0.2.7?

as these are breaking changes, should I upgrade the version to 0.3.0 instead of 0.2.7?

yes, please

Done

Great work, thanks @MrCordeiro


How to find "Potential wasted space" files

Total Image size: 4.4 GB
Potential wasted space: 274 MB
Image efficiency score: 96 %
How to find that 274 MB files?
[Image Details] failed to show all information due to the big image, have to use smaller font to see more lines.

You can get this information via the --json option to output results to a file, including a list of "inefficient files". In the future there will probably be UI adjustments to allow for scrolling in the details pane (or or similar solution).


fix: filter runfiles with whitespace in their paths

Remove runfiles that contain spaces in their filenames, typically seen as gems with poor file naming choices. The --experimental_inprocess_symlink_creation flag is recommended to get around the issue noted in bazelbuild/bazel#4327, but that workaround does not seem to work in bazel build contexts.

Could you please check and fix buildifier errors? https://github.com/bazel-contrib/rules_ruby/actions/runs/7737573441/job/21109769894?pr=73

Thinking out loud, is it really better to silently filter out runfiles with spaces than to fail? Wouldn't it still fail during execution if we drop part of the runfiles and the user would be even more confused as to why it's not there?

Thinking out loud, is it really better to silently filter out runfiles with spaces than to fail? Wouldn't it still fail during execution if we drop part of the runfiles and the user would be even more confused as to why it's not there?

That's a good point, I could see that being confusing. Maybe the filtering could be configured some how? My example is https://github.com/jekyll/jekyll-redirect-from/tree/master/spec/fixtures/tags, where there's a test file with a space in it that seems to be part of the distribution of the gem; the file isn't necessary for the gem to be used.

I had an example same issue with Steep so I had to https://github.com/soutaro/steep/pull/962. Maybe it would be great to filter runfiles, but what do you think if we also print a message about that? Something like Removing "{filepath}" from the runfiles because it contains space(s) (https://github.com/bazelbuild/bazel/issues/4327)..

I'm having some second thoughts on what the issue really is. I tried to reproduce from the solution we arrived at in #72, and I found some interesting things:

jekyll-redirect-from doesn't include the spec/ folder in its .gemspec file
This issue only happens if I run bazel run @ruby//:bundle -- install first
The solution works for the implementation I originally had in #72, but doesn't work for the better solution we arrived at
Getting a fresh cache with bazel clean --expunge was needed after getting into that bad state; if I don't run bazel run @ruby//:bundle -- install first, then I don't need this change

It looks like using bazel run @ruby//:bundle installed things differently and led to those files being left around, but it was bad usage that led to it occurring.

Okay, so I am on the fence whether we need to merge this as-is or do something else. @alexeagle Do you happen to know how other rulesets handle runfiles with spaces?

I don't think this is right, we've never filtered files out of the runfiles in other contexts. I think there needs to be an issue filed on this repo first, showing the existing problem so we can understand what layer the bug is in.

It looks like using bazel run @ruby//:bundle installed things differently and led to those files being left around, but it was bad usage that led to it occurring.

Ok, given the original problem is gone and based on Alex's judgment, I'm going to close this for now. Let's create follow-up issues when somebody runs into the problem.


more docs

Running locally
Deploying to Fly with secrets

fixes https://github.com/supabase/supabase-grafana/issues/2


feat(storage): implement new hummock uploader

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
In this PR, we supported a new hummock uploader.
Detailed can be found at https://www.notion.so/risingwave-labs/Implementation-Details-of-new-Hummock-Uploader-4f1bac068b5f474483f68b657a3c4c8f. Reading the doc is recommended before reviewing the PR.
By the way, hummock storage v1 is totally decoupled with the event handler, and the event handler is decoupled with local version manager after this PR is merged.
Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Refer to a related PR or issue link (optional)

Please add more tests before merging.
@hzxa21 I have added unit tests for the uploader.


Add famsl support

Elevation above mean sea level can be expressed in both meters or feet (mamsl or famsl).
This change introduces a "Use imperial units" setting which can be used throughout the script to determine if distances should be shown as metric or as imperial.
This setting is then used to show the elevation either in mamsl or famsl.
I also tweaked how the number is formatted. It now respects the display rules of the current locale (i.e.  28,891 instead of 28891), which improves readability.

Hello BBosman, thanks for your pull requests!
Can you use the "develop" branch now, instead of "master" for your #11 #12 and #13 PR? You need to make a new PR. We'll merge develop into master later, when we'll have a lots of changes.
Thanks!

No problem. :)
I just recreated the PR's against the "develop" branch.


update date

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 69.886%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
527

Relevant Lines:
759

💛  - Coveralls


FIX: i256 shifts.

Closes #61

Hi Musa, how are you? We appreciate your effort and work on this pull request, but for now, we've decided not to proceed with merging because we believe the change is not necessary. Thank you so much.


Path for saving authentication token should be configureable.

Is your feature request related to a problem? Please describe.
At the moment, when downloading models through the transformers Python package, we get a permission denied error since in our current set-up we have very limited file-system access on where we can read-write but the path for saving the token in the HfFolder class is essentially hard-coded through the path_token class variable.
Describe the solution you'd like
Would be good if you could change the path through an environment variable instead of it being essentially hard-coded to the home directory.
Describe alternatives you've considered
There really isn't an alternative to this problem in cases you can't just write to the home directory other than overwriting the HOME environment variable which is a rather far-fetched solution.

i think this is reasonable given that the file cache can be controlled by an env var, the token cache should be too.
Would you want to open a PR to make this change, @mrkkollo?
You can name the env var something like HUGGINGFACE_TOKEN_CACHE

This value now exists as HUGGING_FACE_HUB_TOKEN (or HF_HOME is general). See reference.


flow-typed needs maintainers

At the moment flow-typed is the suggested way of looking for flow definitions for libraries.
Unfortunately, it is currently maintained by a single person.
I think, keeping definitions up-to-date is as essential to flow adoption as releasing new versions of flow. In fact, if popular libraries won't have up-to-date definitions available, developers may not be able to upgrade to the newer flow versions. That will make flow release frequency irrelevant - nobody will use it anyways.
Please, join flow-typed.
Another solution might be to come up with a way to piggy-back on TypeScript definitions if nobody wants to maintain flow-typed.

I wonder what are incompatibilities between type systems. TypeScript known to be unsound, but Flow is sound.

@stereobooster Flow is not sound. There are plenty of open issues here related to soundness. Flow simply aims to be sound, whereas TypeScript does not.

Yes this what I meant. Thank you for correction

https://github.com/joarwilk/flowgen is a project that does a good job at outlining the differences between the two definition languages. The issues with converting between the two not very abstract issues, but concrete ones like "how do we convert namespaces from TS to objects in flow?"

All discussions about flow-typed are moved into discord channel.


replaced compose, curryN with own implementations

Closes #37.

Just saw #2. The curry version I've implemented does not support Ramda's placeholder, and there are no tests that verify it or any mention in the docs.
If it's a requirement, there's probably a lot less to gain from removing the dependency.


Address issue #70 and create an error message if old player.json is used

Converts the 'Show unowned crew' checkbox to a dropdown with the options of "Show all", "Only show unowned crew" and "Only show owned crew". Also introduces an error message when the user uses a player.json file with client_id < 17 instead of a blank page.

That's a nice addition and it works well! Just a few suggestions:

Could we match the style of the minimum rarity field (or vice versa)? They look like different types of elements, even though I think they should be the same.

Could we filter out immortals from the owned list, so that it's more like "Owned crew I need stars for"?

Could we only show the new error after the fetching of keystones and crew is completed and the data is found to be invalid? Right now it shows the error while the fetching is occurring, which is somewhat misleading, even if it's only for a second or so.

Huh, it hadn't occurred to me that people would try with old versions, but makes a lot of sense. Thanks!

Could we filter out immortals from the owned list, so that it's more like "Owned crew I need stars for"?

Agreed but we need to make it explicit. Perhaps the option should be "Only show unowned crew not FF" or such?
To implement that we'll need to find the max stars on a copy of a crew in player inventory. Once we have done that it should be trivial to implement #60 by passing the player_roster_max_stars_for_crew (not suggesting this should be final name) to the Rating component where we currently pass crew.rarity. So if you want to tackle that too, that would be amazing.

I've addressed points 1 and 2

Huh, it hadn't occurred to me that people would try with old versions, but makes a lot of sense. Thanks!

In my experience IT project always suffer from the problem that their designers/programmers only consider how their product should be used and not how it might be misused.


Allow to use ECR replication

Allow to use ECR replication
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/ecr_replication_configuration

Closes https://github.com/cloudposse/terraform-aws-ecr/issues/99

can someone run tests?🙂

@dmitrijn can you please address the linting issues in your new example as well? Thanks!

@dmitrijn friendly ping on this -- want to wrap this up with the requested changes and we'll get it merged?

@Gowiem please run tests.

@Gowiem please run tests.

@dmitrijn this one is close, can you make the remaining change so this can be merged?

@hans-d I took this one over, can you review?

/terratest


training cost

What graphics cards were used for training and how long did the training take?

Tesla V100. It only needs 60 epochs to achieve the best performance.


problem with GPy

Hi Scott and Matt,
Really sorry that I am sending the second issue in one day. I interested to use pgmult with GP which is explain in examples/multinomial_gp.py.
$ python examples/multinomial_gp.py
This program needs access to the screen.
Please run with a Framework build of python, and only when you are
logged in on the main display of your Mac.

It seems it is an issue with GPy but not sure. If you feel this is not relevant to your package, please close it.
Thanks,
Kayhan

It seems the issue is with wx backend. If I run the code with pythonw examples/multinomial_gp.py it runs.
ref: http://stackoverflow.com/questions/24134850/wxpython-on-python-3-miniconda-environment

Hmm so should we close this issue, or is there something to fix in pgmult here?

multinomial_gp.py needs GPy package and GPy needs wx. I opened this issue with GPy:
https://github.com/SheffieldML/GPy/issues/387
It seems wx is somewhat broken in mac if I understand it correctly from here:
http://matplotlib.org/faq/virtualenv_faq.html
So, you can close this issue. I don't think you can fix it because there is something wrong with GPy dependency.
Thanks,

Cool, thanks for the thorough investigation!

Response from the GPy issue:
"
Yes try using python3 and import matplotlib before importing GPy. Also look at your ipython config, which should say backend=macosx.
"
can I use pgmult with python3 ?

I don't think we've ever tried it so there would probably be some bumps with python 3, but nothing should be impossible to update.


RFD - A11y Testing Phase 1

Status
Proposed

Author(s)
@gabalafou

Date Created
12-04-2022

Date Last updated
12-04-2022

Decision deadline
19-04-2022

Six week testing marathon
A word of acknowledgment: many of the thoughts below are not my own. I could not have produced this document without Tony. I have also been aided in discussions with Isabela and Tania. My thinking has also been shaped by online discussions from people in the web a11y community, as well as the JupyterLab benchmarks repo.
Summary
Refresher—our CZI grant comprises essentially three steps:

Test (JupyterLab for accessibility issues)
Fix (issues in JupyterLab)
Share (learnings with the wider open source community)

What are Tony and I hoping to solve over the next six weeks? We haven't made significant progress yet on the CZI grant deliverables, in particular the first one, testing. We hope that by rallying together as a team, we can make significant progress towards our testing deliverable.
User benefit
This section is mostly a discussion of testing philosophy. It attempts to articulate a justification for testing, upon which the concrete proposal is based. But if you just want to get to the proposal, jump to the next section.
So what is testing trying to solve? Over the past months, I've heard everything from motivating developers to fix accessibility issues by creating squeaky-wheel CI failures to helping developers understand how their code changes affect accessibility.
A similar challenge of scope is that JupyterLab accessibility issues touch upon so many distinct and disparate areas, not only the JupyterLab app, but also JupyterLab docs, extensions, and other critical parts of the ecosystem (viz., the notebook reader experience versus the notebook writer experience). However, the automated testing needs of docs are fairly different from the needs of a stateful, interactive web app like JupyterLab.
So what is testing trying to solve? In an ideal world, I think it solves the issue that Tania has mentioned in previous team meetings: giving us a "control room" view of what's broken, what needs to be fixed—letting us know where we are.
But I don't think we can actually build that. For one, there's an issue of limited resources. And for another, there's an issue that some of the most important accessibility issues are impossible to automate (for example, basically everything semantic: good link text, logical and meaningful headings, etc.). So, at most, we can get a limited control room view of things that the computer thinks need to be fixed.
So I reject this raison d'être for tests. I don't believe that they are there to let us know the state of accessibility. I believe that they serve a purpose that is closer to what other automated tests serve, which in my experience is some combination of helping to document the expected behavior of the app, to catch bugs before they happen, and to prevent bugs from re-occurring.
Where this analogy breaks down is that for general software testing, if you have a very good suite of tests, then you can believe with some confidence that if your tests pass, the application will behave as expected—in theory, anyway. But with accessibility, there is no set of accessibility tests you can run that will give you fairly high confidence that if the tests pass, your application is "accessible," any more than there are a set of security tests you can run against your application and be confident that your application is "secure." As with security, all you can do is use tests to help you avoid common pitfalls.
So in my view, the main problem that testing is trying to solve is to help us avoid common pitfalls. If we avoid those pitfalls, we decrease the chance that some user will struggle with a particular aspect of our application (for example, color contrast).
This distinction is important because I believe that everything we do should be justified by the criteria of: does this help make and keep the app more accessible? I think automated testing can help us make accessibility gains, but even more powerfully help us to keep the gains we make.
So in my mind, that's the main purpose. For the purposes of our grant, there are some additional purposes that testing can serve:

Helping to document things we've fixed along the way
Increasing the visibility of existing pitfalls in JupyterLab
Providing a potential pathway to contributions from developers who are motivated by CI or by flipping reds to greens on a test report
Providing a potential pathway to developers who like writing tests
and more!

Proposal
Okay, with the why's and wherefore's of the previous section out of the way, now that you understand what overall purpose I think testing serves, in this section I will make a six-week proposal that I think addresses that purpose.
Why six weeks? It's an artificial deadline with not much purpose other than to motivate us. It's also an amount of time that I believe is long enough to produce a significant deliverable. I have divided the proposal into three parts, each with an independent but related deliverable.
Part 1.
A software package to run a suite of accessibility tests against any app code PR in JupyterLab (by app code, I mean this does not cover docs yet—visit section below for longer discussion). To begin, our test test suite will include:

Standard axe-core diagnostics against three to five JupyterLab "views"
Three to five handwritten machine-as-a-user tests (i.e., Playwright)

Part 2.
Utilize a service (i.e., GitHub actions) to make it easy for any PR author or reviewer to run our accessibility test suite against their PR. For example, someone could type "Run accessibility tests" in a PR comment and that could trigger a bot to run the tests and report back in a comment on the PR.
Part 3.
(Beyond six weeks, or six-week stretch goal)
Configure a scheduler to run the test suite on a regular schedule and figure out how and where to publish the results to maximize impact and visibility.
The division of the project into three parts makes it look like these parts are sequential, but a lot of the work should probably be done in parallel.
Timeline
This is more of an example timeline than a real timeline proposal. This is just to give an idea of how the work might be broken up by time and by team member.
Week 1. (this week). Team alignment (this document).
Week 2. Get axe-core tests into jupyter/accessibility

Tony to get Python, Doit, and environment working
Tania to help configure CI
Isabela to work with Tony to define 2-4 "pages" to feed to axe-core (keeping color contrast front of mind)
Gabriel to pair with Tony to help set up pages for axe-core

Week 3. Set up axe-core tests for storage and sharing (GitHub comment on PR, for example)

Isabela to select and define 1-2 tests for Playwright + Galata (keeping color contrast front of mind)
Gabriel, Tony and Tania to work on wrangling GitHub's CI system

Week 4. Add scaffold for Galata + Playwright tests to jupyter/accessibility

Isabela to select and define 1-2 more tests
Gabriel to work on how to mush together axe-core with Playwright tests
Tony and Tania to start working on how to format and store test results

Week 5. Implement 1-2 of Isabela's tests in Galata + Playwright (again, keeping color contrast front of mind)

Gabriel to wright (err, write) the Playwright code to turn half of Isabela's tests from human-readable instructions to machine-readable instructions
Tony and Gabriel to implement code needed to store tests results
Isabela to start planning for next focussed team work cycle

Week 6. Implement rest of Isabela's tests in Galata + Playwright. Make sure results are getting stored in the right place and that test results are shareable via easy mechanism (i.e., GitHub action).

Gabriel to finish implementing last of Isabela's tests
All hands on deck to help test and debug our integration with Github CI

Alternatives
The main thing I want to point out in this section is that the proposal I am making for the next six weeks does not include other crucial aspects of the JupyterLab ecosystem, such as docs, not to mention the even broader Jupyter ecosystem, such as Lumino and RetroLab. This is not to disregard those other parts. It is rather in order to reduce complexity and sharpen focus for this testing phase. This is why I'm calling it "Phase 1."
In order to address this critical shortcoming, I recommend coming back to testing, as a team, a few more times over the course of the grant—i.e., A11y Testing Phase 2, Phase 3, and so on. I wonder if a good approach would be for us to work in cycles, going from testing to fixing to sharing, then back again to testing, fixing, and sharing, and so forth and so on. The reason I think this could be a smart approach is that I believe that when we work on fixing accessibility issues and then on sharing what we have accomplished so far, we will learn things that will inform and improve our approach to testing. There is also a benefit to working on something, putting it aside for a while, and then revisiting it with renewed eyes.
Addressing concerns
In this section I would like to discuss three concerns about this work. I will point out the strategies we seem to have informally adopted as a team so far, and I will point out where I think there are still open questions.
Concern 1: Disrupting the developer workflow
Tania has repeatedly voiced a concern that our work should not impede the developer workflow. I think we have managed to address this concern by using the jupyter/accessibility repo, following the pattern of the benchmarks repo, so that our envisioned testing infrastructure becomes a value add-on to the developer workflow and not a blocker for any development.
Concern 2: Maintenance burden
Any software package or system that we build represents a potential maintenance burden for our already small team. Yes, we'll be open-sourcing all of our work, but I fear that at least in the beginning, if anything breaks, it will be on us to fix it. Maintenance becomes an even more crucial issue if our work gains traction (which we want!). We want traction and adoption because that's a measure of success, but that also raises the stakes for when things break.
I'm not sure what measures or principles we are adopting to address this concern. It seems to me that one thing we should consider, at least in the initial phase, is to avoid putting a software package out there that we intend for developers to use on their own machines. This might be antithetical to the ethos of open source software (I'm not sure); however, I think we will be doing ourselves a solid favor if we clearly communicate that we haven't done the legwork to make sure that the testing code we write can run on a wide range of developer machines. That would free us to focus on making our package run only on specific environments that we control.
Question: what other principles, guidelines, strategies can we follow to help prevent creating a big maintenance burden for our small team?
Concern 3: Misinterpretation of test results
I have been somewhat squeamish about automated accessibility testing from the beginning because one of the first things I watched after I joined Quansight was a presentation by an engineer who showed how you could create a website that is literally accessible to no one and yet still get a perfect Lighthouse accessibility score.
It's true: developers are responsive to charts and metrics. That is a blessing and a curse, a challenge and an opportunity for the work we do with automated accessibility tests.
I am afraid of building a tool that misdirects human energy. I am still very concerned that our efforts will be misinterpreted.
Unfortunately, having this concern kicking around in my head for months has not yet produced a eureka moment for me. Writing this document has helped give me some clarity about how to message automated accessibility tests (i.e., "avoiding pitfalls" versus "state of accessibility"), but I'm not convinced this will be enough to prevent misinterpretation.
Here's an example scenario that I think we may be setting ourselves up for. Imagine that a JupyterLab developer submits a PR. They know about our suite of accessibility tests and how to run them against their PR.  The developer is thrilled. Their code change has passed our suite of tests. A11y... Check! But then one of us comes along and spots an issue and then for the 100th time we have to explain that, well, um, the tests are not really comprehensive, a green light isn't really a green light etc etc.
Maybe this isn't that significant. Maybe I am making a mountain out of a mole hill. Maybe all of the benefits of automated accessibility tests outweigh the likely misinterpretations. But wherever possible I would like us to try to minimize the kinds of misinterpretations that we can expect, knowing what we know about how software engineers think.
How do people working in security testing address this issue? (As in, "if your code passes our automated security checks, it doesn't actually mean the code is secure, just that it avoids common security pitfalls.")
Perhaps this is an area in which Isabela could help us come up with good visuals that help to communicate the limitations of our system.
What's next?
After Phase 1 of a11y testing, I would like to put forward Tony's proposal that we move into a team-coordinated cycle of fixing issues in JupyterLab, beginning with color contrast. Maybe we spend three to six weeks on color contrast. Then spend a couple weeks writing up what we did. Then return to a testing cycle. Then a fixing cycle. Writing up our results. And so on.

☕  I recommend you grab a cup of your favourite brew before reading

similar challenge of scope is that JupyterLab accessibility issues touch upon so many distinct and disparate areas, not only the JupyterLab app but also JupyterLab docs, extensions, and other critical parts of the ecosystem

This is true and for reference, I created a top-view of what all these things in the statement cover within the Jupyter ecosystem... it is a lot and there is for sure no way we make all of these moving pieces together accessible... not us not with the resources we have

So what is testing trying to solve? In an ideal world, I think it solves the issue that Tania has mentioned in previous team meetings: giving us a "control room" view of what's broken, what needs to be fixed—letting us know where we are.

I feel we have a very different view of the role and context of "testing" per se (my own personal opinions)

Testing solves nothing the purpose of any sort of test is not to fix/remediate/solve issues (this is widely applicable to any area of software development)
What testing is and how it should be treated:
a. A diagnosis tool - either to reveal the current status of the codebase or to identify potential Root Causes (RA) to issues or unexpected behaviours arisen
b. A Quality assurance tool: how are we sure that our tool does what we say it is doing? and if it is not, what promises are we breaking? who and how are being affected by these failures? How can I (e.g. a developer/contributor) make sure that what I am adding to the codebase does not break already existing features?
c. A learning mechanism: what can we learn from the array of passed/failed/inconclusive tests? how can we use this data to learn from and improve our processes and tooling?
d. An imperfect proxy to identify failing assumptions
e. Finally, the most common of all - a final switch to prevent bugs from reaching the end-user

Also, note I am not referring to automated testing with the above, since testing != automated testing - I am talking about a holistic testing approach (or mixed methods approach - automated, manual, etc.)
With those principles' in sight, we can build a framework that gives us much valuable information on where we are standing: not only on what is broken and needs fixing but also on what assumptions we are making down the path.
It is not a direct metric of JupyterLab is 85% accessible because even if we managed to align with all of the WCAG principles and criteria that still does not give us any insight on functional accessibility.
Maybe  this is a promise not one single tool/IDE/app will make - I have not yet seen anything out there that gives you a hard metric for all levels of accessibility, because I dare to say this is impossible.

the most important accessibility issues are impossible to automate
This statement here makes me feel the broader testing is being conflated with automated testing though I might be wrong.
However, this also opens up another important question - who is responsible for what in the context of Jupyter accessibility, and what should we aim to do to fix it?

So I present exhibit B:

Many of those concerns about items to be automated do not fall under things we (or the broader Jupyer folks) can solve/nor have responsibility for.
Since all of these fall in the category of "content generated inside a notebook" the responsibility lies in whoever is generating said content. How can we possibly "test" and fix all notebooks in the wild? We can not - neither we want to.
So centring back what is in scope for the grant?   Enter Exhibit C

JLab is within our scope - that is, from a software project point of view the sole scope for Phase 1 of the grant. And by sibling association, this will affect other tools that use JLab (i.e. BinderHub, JupyterHub). Anything else is far beyond our promise (I know it sucks, but that is what is for now)
And how can we make a positive, progressive, and more important long-term impact within our "narrow" scope? Enter Exhibit D

This is not one pass, and it's done - but a rather iterative or build-on-iterative where the most valuable piece is not the unit tests or even the Playwright scenarios - but the creation of evidence & experience-based practice and documentation for accessibility within JupyterLab (and beyond).
This workflow has plenty of assumptions but it integrates many of the concerns that @gabalafou  mentioned:

How are we disrupting the developer workflow? We have plans to mitigate this -> we might be again making assumptions on this, but the truth is we will not know until we get stuff out and people start using it
Maintenance burden -> all software comes with that, we do want this to become a useful tool and even more so a sustainable one. We have to create participation pathways for folks to ensure sustainability.
Operate under the assumption (and more often true than not) that users will use your product/tool in unintended ways. There is maybe no way around it but what we can do it set very explicit contracts re what our tool does/what it does not/what guarantees we can make (OSI licenses take care of some of this) and document, document, document.
How can we ensure that whatever our tests report on are not misinterpreted - well document document document... make assumptions explicit, clearly word what those numbers mean from a functional and technical point of view. Build supplementary material. That is what the SevDevOps folks do - there is only as much as you can do because accessibility like security is not one single person's job it is everyone's job.

Now on the proposal, I do agree with the following:

A software package to run a suite of accessibility tests against any app code PR in JupyterLab (with the understanding that docs comes later on and is not within the immediate scope of Phase 1)
GH actions based report/call to tests
Cron -based automated testing

Based on the timeline proposed by @gabalafou  - and accounting for the delay in getting the RFD reviewed:

gantt
    title 6 weeks "sprint"
    dateFormat  YYYY-MM-DD
    section Week 1
    RFD - team alignment  :a1, 2022-04-12, 10d
    section Week 2
    Get axe-core tests in a11y repo  :2022-04-21, 7d
    section Week 3
    Setup axe-core tests for storage and sharing :2022-04-28, 7d
    section Week 4
    Add scaffold for Galata + Playwright tests to jupyter/accessibility :2022-05-05, 7d
    section Week 5
    Implement 1-2 of Isabela's tests in Galata + Playwright :2022-05-12, 7d
    section Week 6
    Implement rest of Isabela's tests in Galata + Playwright. :2022-05-19, 7d

There are items that are already out of sync, and the original timeline does not account for my PTO, so needs adjusting.

Decision
That said - with the discussion items and the many caveats in the comments, I propose the vote:
👎🏽  - Reject the RFD
👍🏽  - Approve as is
🚀  - Approve the scope, workflows and mitigation plans proposed in https://github.com/Quansight-Labs/jupyter-a11y-mgmt/issues/97#issuecomment-1104334128
@Quansight-Labs/czi-a11y-grant  team vote today by 11:59pm PDT after which the lazy majority will be counted as final decision

Note if approved - this will be taken as the source of truth for the upcoming 6 week sprint cc/ @Quansight-Labs/czi-a11y-grant

I love love love this discussion!
I clicked the 🚀 , let's go! 😸
The next section is addressed to @trallard's comment.

@trallard, you were spot on in picking up that something that I failed to make explicit in my document is that I narrowed my scope to automated testing. You're right in pointing out that accessibility testing encompasses a much broader scope that includes non-automated, human testing. The question this raises for me is: are there things you think we should be doing on manual testing in year one of the grant? if so, which things?
I also really like how Exhibit B exposed another implicit narrowing of scope in my document. I was only thinking about Jupyter folks (maintainers, developers). I wasn't thinking about content creators and consumers (notebook authors and readers). That is a very important piece of the puzzle when thinking about the accessibility of the entire user experience of reading and writing notebooks in JupyterLab and its associated ecosystem.
And beyond that, as you show in Exhibit B, the user experience is also shaped by the broader ecosystem (what's happening in browsers, standards, assistive tech, government, etc.) and I think it's important not to lose sight of our position within that ecosystem, as well our push and pull. For example, we may be able to offer a valuable perspective at the W3C.
@trallard, are any of your diagrams in Mural by chance? I would love to be able to comment and ask questions directly on some diagrams.
As for our differences in the role and context of testing per se, I must have simply misunderstood what I was hearing you say in past meetings. In your comment, the way that you broke automated testing down into 5 parts makes me think we are actually more aligned than I realized (yay!).
a. Diagnostics ✅
b. Quality assurance ✅
c. Learning mechanism. I don't think I called this one out explicitly but yes, I totally agree ✅
e. Proxy... not sure what this one means
f. Bug prevention ✅ ... although... how is this one different from (b) quality assurance?
The next section is addressed to @isabela-pf's comment.

I think this requires us documenting the state of tests at different points in time and/or aligned with commits. Is there plans for this, or is this just an idea to consider?

Yes, there are multiple ways that having automated tests can help us "document things along the way."
The first and most basic is just the set of tests that we have. This set should grow over time and that growth will be captured in our git commit history.
Second, the part 3 of my proposal specifically addresses running the tests periodically and capturing the results of those tests. This should allow us to create a time series that helps to document some of our work and progress along the way.
Another way that tests can help to log our progress is if we align them with commits to the JupyterLab repo. As Nick discussed in the JupyterLab accessibility call today, we should be able to plug our automated a11y testing system into the tools that the maintainers use to update the change log whenever they cut a new JupyterLab release.

Naive question, does this refer to the different layouts in JupyterLab? For example, Lab itself, “simple mode,” etc.?

No, I used the term app code mostly to distinguish from documentation source code. But layouts fit within the scope of app code. When running axe-core tests, we'll probably want to test all such layouts.

Depending what “sharing” includes, I think this could be the least frequent part of the section. If sharing means “demos at JupyterLab or community calls”, for example, I think that could be done in the order you mentioned. If sharing means “documenting and bringing it to other parts of the ecosystem” I think it will be less often.

Yeah, I'm not entirely sure what the form of sharing should take and am totally open on this. I just think it would be a good idea if we build in sessions throughout the grant to work on the part of the grant that has to do with sharing/publishing our results. My mental model of the grant is:

Testing
Fixing
Sharing

As I was working on this six-week proposal, I realized that testing would probably benefit from an on-off rhythm: working on it, then stepping back, then working on it again, then stepping back, etc. Same for fixing. Same for sharing. I'm thinking that rather than save the sharing step for the very end of the grant we could come back to it repeatedly over the course of the grant.
Tony thinks we should maybe have a sharing or reflection cycle (to be clear, not a six weeks-long cycle!) at the end of each other major cycle of work. We do six weeks of testing, then we work together for a week to collect our findings from that cycle (perhaps in a blog post) and plan the next cycle. Then we could do, for example, a six week fixing cycle and then stop and do another quick retrospective. And so on.
But I should say I'm not opposed to saving the sharing part of the grant for the end. I'm just thinking that it might help with team spirit and public relations if we are periodically celebrating and sharing what we've done with the wider world.

Nor mural but lucid (shared the link in slack). And you can add comments there 😜


[fix] Fix visualizer quirks with big topologies #176

The previous patch in #176 did an asynchronous request to fetch NetJSONGraph data. If the request promise didn't resovle before initialization of the graph (i.e. it took a long time for a response), then the graph was initialized with the default graphConfig. This caused the logic added to disable layoutAnimation to become obsolete.
This patch fixes this issue by updating graphConfig in NetJSONGraph.onLoad.
Related to #176

Coverage: 99.328%. Remained the same when pulling f2bce5f7bb5219ffaa1b4e9507be61ec3dac73ef on issues/164-network-topology into 4310967dd3ed89fa6ad12765e36afa882d42c8b5 on master.


XRCE multithreading not supported for this platform - FreeRTOS - wrong flag

From https://github.com/micro-ROS/micro_ros_setup/issues/312
I was trying to enable multithread support, however, I got
eProsima/Micro-XRCE-DDS-Client/src/c/profile/multithread/multithread.c:23:2: error: #error XRCE multithreading not supported for this platform.

By quickly skimming the code, it seems the wrong flag is used for FreeRTOS. I'm using FreeRTOS+TCP, on the base CMakeLists.txt, this sets UCLIENT_PLATFORM_FREERTOS_PLUS_TCP, on the other hand, https://github.com/eProsima/Micro-XRCE-DDS-Client/blob/foxy/src/c/profile/multithread/multithread.c#L13 expects to be PLATFORM_NAME_FREERTOS. As a workaround, I can set the flag on my colcon meta, but I think it's not the intended behavior.

Yes, this was the intended behavior because FreeRTOS does not have a common set of flags for checking when it is being used, so the user is in charge of defining PLATFORM_NAME_FREERTOS. The point is that UCLIENT_PLATFORM_FREERTOS_PLUS_TCP only refers to a TCP/UDP transport layer and FreeRTOS can be used with other transports.


ORY custom post reconcile action regenerates JWKS and patches secret even if not required

Description
ORY reconciliation actions causes unnecessary jwks regeneration and deployments restart.
This is error-prone in the scope of single cluster and imposes computational resources problem for the reconciler.
Expected result
JWKS should be regenerated based on detection mechanism ( i.e when existing one on the runtime is missing or corrupted )
Actual result
JWKS is regenerated and Secret is patched with every reconciliation causing ory deployments to be redeployed every time reconciliation is performed
Steps to reproduce
Build reconciler binaries
make build-darwin

Run ory reconciliation locally against any kyma runtime:
./bin/mothership-darwin local --components ory  --kubeconfig {path to your cluster's kubeconfig} --value global.domainName='{your cluster's domain}'

https://github.com/kyma-incubator/reconciler/pull/356

still we need to modify ORY chart

Decided to just create once this secret, so we will need to remove some jobs and change Ory Helm Chart regarding this secret.
For rotating this secret in Kyma 1.x, there was a cronjob responsible for that, we can also implement that in the reconciler.

https://github.com/kyma-project/kyma/pull/12550

@mjakobczyk & @piotrkpc doing review


Floats or Integers for numbers

A lot of microcontrollers don't have an FPU or the ability to use floats. For the devices I'm planning to use this crate for (my laptop, raspberry pi, and STM32) this isn't an issue, so I've gone with the easy option and used floats everywhere.
Is it worth swapping to use i32 instead, or even some wrapper struct which can represent an i32 which is meant to be premultiplied to give x digits of precision?
trait IntegerNumber {
    // Number decimal digits of precision this int has.
    // (a precision of 2 means to get the decimal
    // representation you'd divide by 10^2)
    fn precision() -> u32;
}

struct TwoDigitInt(i32);

impl IntegerNumber for TwoDigitInt {
    fn precision() -> u32 { 2 }
}

impl Deref for TwoDigitInt {
    type Target = i32;
    fn deref(&self) -> &Self::Target {
        &self.0
    }
}

If the architecture you are working on doesn't support floats and you want to use this crate, let me know as a comment so I know this feature is desired.

This isn't really necessary. As far as I know, all the architectures Rust targets have a native FPU.


Access denied in ECR

Description
In Git Actions I got errors.
Error response from daemon: pull access denied for ***.dkr.ecr.ap-northeast-2.amazonaws.com, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

I assume that this is because of wrong ecr url like #107

Sovled
Yes. As we expect, this is wrong ecr url problem!

URL from : ***.ecr-registry-example-com
URL to : ***.ecr-registry-example-com/registry


[DS-4001] Set the primaryBitstreamID only if the bitstream has not been deleted…

…. Otherwise a deleted primary bitstream is still referenced in the bundle table which results in a deletion violates foreign key constraint error during a bitstream cleanup task.
References
https://jira.lyrasis.org/browse/DS-4001
Fixes #7348
Description
See comment: https://jira.lyrasis.org/browse/DS-4001?focusedCommentId=65591&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-65591

@misilot We get those too, on a v5.6 instance.  Here's the note I wrote for myself on how to cope with it:

DSpace 1-5:
\set a BITSTREAM_ID
SELECT bundle_id AS b FROM bundle WHERE primary_bitstream_id = :'a';
\gset
SELECT * FROM bundle2bitstream WHERE bundle_id = :'b';
-- Is bitstream A in bundle B?  Yes:  problem?
SELECT deleted FROM bitstream WHERE bitstream_id = :'a';
-- Deleted?  No:  problem?
UPDATE bundle SET primary_bitstream_id = null WHERE bundle_id = :'b';
DSpace 6+:
\set a BITSTREAM-UUID
SELECT uuid AS b FROM bundle WHERE primary_bitstream_id = :'a';
\gset
SELECT * FROM bundle2bitstream WHERE bundle_id = :'b';
-- Is bitstream A in bundle B?  Yes:  problem?
SELECT deleted FROM bitstream WHERE uuid = :'a';
-- Deleted?  No:  problem?
UPDATE bundle SET primary_bitstream_id = null WHERE uuid = :'b';

Similar to yours, if a bit more timid.  I have never yet seen a situation where my tests caused me to abandon the operation.
(There is another problem here:  dspace cleanup does its work in a single long-running transaction, and throws all that work away (except for file deletions!) if any part of it fails.  There is no need for that.  We should do the cleanup of individual bitstreams in individual transactions.  The current code actually leaves the model in an inconsistent state, with references to files that no longer exist.)

Thanks @mwoodiupui

(There is another problem here: dspace cleanup does its work in a single long-running transaction, and throws all that work away (except for file deletions!) if any part of it fails. There is no need for that. We should do the cleanup of individual bitstreams in individual transactions. The current code actually leaves the model in an inconsistent state, with references to files that no longer exist.)

This is what I was figuring was happening. It is just will be a very time consuming process as it tries to delete the bitstreams in the long running transaction before it fails. (Hoping there won't be too many records to check, but probably the safest option). At least I am running this on a dev instance first :)

@mwoodiupui,
I am trying to walk through your SQL steps (looks like we might have ~19000 items to evaluate. Should this be UPDATE bundle SET primary_bitstream_id = null WHERE uuid = :'a';  with a reference to a instead of b?

I am trying to walk through your SQL steps (looks like we might have ~19000 items to evaluate. Should this be UPDATE bundle SET primary_bitstream_id = null WHERE uuid = :'a';  with a reference to a instead of b?

No.  'b' is the UUID of the bundle that we are repairing.  'a' is the UUID of the bitstream that has the problem.  This query is to
clear the primary bitstream of a specific bundle:  the bundle with its primary bitstream referencing the bitstream that we want to purge.
When I am cleaning up these pinned bitstreams, I just cut and paste from my notes into a terminal window, so what I posted to this issue has been run dozens of times as you see it.  (I do the pasting a bit at a time so that I can answer the questions in the comments, because I'm wary of altering the database "manually".)
I might have used better names for 'a' and 'b'....
Oh!  I see other problems in your transcript.  That first SELECT should find more than 0 rows.  Are you quite certain that the \set above it is giving the UUID of the bitstream that cleanup is trying to purge?  If b has no value, we may expect problems further down in the procedure.

This took an hour to get (yay for the long running transaction)
2021-03-23 17:23:48,014 ERROR org.hibernate.engine.jdbc.spi.SqlExceptionHelper @ ERROR: update or delete on table "bitstream" violates foreign key constraint "bundle2bitstream_bitstream_id_fkey" on table "bundle2bitstream"
  Detail: Key (uuid)=(cb5d26a1-e42e-4e25-8081-726ea70b3aaa) is still referenced from table "bundle2bitstream".
2021-03-23 17:23:48,017 FATAL org.dspace.storage.bitstore.Cleanup @ Caught exception:
org.hibernate.exception.ConstraintViolationException: could not execute statement
        at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:129)
        at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:124)
        at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
        at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:189)
        at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3358)
        at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:3558)
        at org.hibernate.action.internal.EntityDeleteAction.execute(EntityDeleteAction.java:102)
        at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:395)
        at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:387)
        at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:310)
        at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:349)
        at org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:67)
        at org.hibernate.internal.SessionImpl.autoFlushIfRequired(SessionImpl.java:1166)
        at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1616)
        at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.java:374)
        at org.dspace.core.AbstractHibernateDAO.list(AbstractHibernateDAO.java:158)
        at org.dspace.content.dao.impl.BitstreamDAOImpl.findDuplicateInternalIdentifier(BitstreamDAOImpl.java:58)
        at org.dspace.content.BitstreamServiceImpl.findDuplicateInternalIdentifier(BitstreamServiceImpl.java:368)
        at org.dspace.storage.bitstore.BitstreamStorageServiceImpl.cleanup(BitstreamStorageServiceImpl.java:292)
        at org.dspace.storage.bitstore.Cleanup.main(Cleanup.java:79)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at org.dspace.app.launcher.ScriptLauncher.runOneCommand(ScriptLauncher.java:229)
        at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:81)
Caused by: org.postgresql.util.PSQLException: ERROR: update or delete on table "bitstream" violates foreign key constraint "bundle2bitstream_bitstream_id_fkey" on table "bundle2bitstream"
  Detail: Key (uuid)=(cb5d26a1-e42e-4e25-8081-726ea70b3aaa) is still referenced from table "bundle2bitstream".
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2422)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2167)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:306)
        at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:441)
        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:365)
        at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:155)
        at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:132)
        at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:98)
        at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:98)
        at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:186)
        ... 22 more

I was assuming that "cb5d26a1-e42e-4e25-8081-726ea70b3aaa" would be "a" in the statements above, but maybe not?

Does anyone know if any of this might have been addressed in 7x? I'm just trying to figure out if I need to circle back to this on 6.4, or just push it and work on trying to upgrade to 7x?

@misilot This is not fixed yet in DSpace 7 and I can confirm that there are also issues with constraints not being met in cases where the bitstream being deleted has entries in the requestitem table (if you have enabled the request a copy functionality in your repository):
Caused by: org.postgresql.util.PSQLException: ERROR: update or delete on table "bitstream" violates foreign key constraint "requestitem_bitstream_id_fkey" on table "requestitem"
  Detail: Key (uuid)=(2797e3c1-6a4b-4bae-ad0d-87438f4ed216) is still referenced from table "requestitem".
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2676)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2366)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:356)
        at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:490)
        at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:408)
        at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:181)
        at org.postgresql.jdbc.PgPreparedStatement.executeUpdate(PgPreparedStatement.java:149)
        at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
        at org.apache.commons.dbcp2.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:136)
        at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:197)

@amgciadev : The "Request a Copy" issue you are talking about is has a fix coming soon in #8660 (likely to be included in 7.5)


fix(Divider): your description

Steps to Reproduce

Use Google Chrome to access the testcase

Expected
Divider splits sections of Lorem Ipsum Vertically, with vertical lines appearing
Result
Vertical dividers did not appear, nor the text "OR" or "AND" as listed in the example code. They appear to be rendering to the far left of the example. Screenshot attached.

Testcase
https://react.semantic-ui.com/elements/divider#divider-example-vertical

@lenaguerrero This is actually an issue with the W3C spec change causing this bug in the CSS. It is documented in the SUI core repository:
https://github.com/Semantic-Org/Semantic-UI/issues/4342


Account Management

Develop the account management related features
(This group of screens will allow the user to Create Import signum accounts)
To discuss

[x] https://github.com/signum-network/signum-mobile-wallet/issues/13

Stories:

[x] https://github.com/signum-network/signum-mobile-wallet/issues/7
[x] https://github.com/signum-network/signum-mobile-wallet/issues/8
[x] https://github.com/signum-network/signum-mobile-wallet/issues/9
[x] https://github.com/signum-network/signum-mobile-wallet/issues/14
[x] https://github.com/signum-network/signum-mobile-wallet/issues/15
[x] https://github.com/signum-network/signum-mobile-wallet/issues/10
[x] https://github.com/signum-network/signum-mobile-wallet/issues/11
[x] https://github.com/signum-network/signum-mobile-wallet/issues/12

Final PR regarding initial account management is merged
https://github.com/signum-network/signum-mobile-wallet/pull/21


[IOTDB-3724] Fix Incorrect result when querying with linear fill & order by time desc

Coverage decreased (-0.003%) to 45.898% when pulling a7e61084471dc3a47c3154dd7e7cfae455b82b55 on IOTDB-3724 into ccf895a20e66965739e9ce1a16a5f4f72310a46b on master.


minimal-bootstrap.gcc-latest: init at 13.2.0

Description of changes

Feels like we are on the home stretch!
Related #227914
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@emilytrau I don't mind if you just self-merge these things because the stuff I cared about we agreed to return to afterwards.

Awesome

@emilytrau I don't mind if you just self-merge these things because the stuff I cared about we agreed to return to afterwards.

I couldn't even if I wanted to. I'm not a committer :p


Minor improvement: add keyboard support for attributes popup

Very minor thing for now:

when adding attributes to a user
it gets quite annoying to enter text + press a button
it'd be much faster if we can press ENTER on the keyboard and see the attribute

Tbh if you use TAB to centre on the "Save" button, it's going to work as well.
So this might not be needed at all.


When using get_catalog_item and trying to get relationship the code fails.

Describe the bug
When trying to get relationships for ASIN using get_catalog_item as per https://developer-docs.amazon.com/sp-api/docs/catalog-items-api-v2022-04-01-use-case-guide
Exact error:
Traceback (most recent call last):
File "D:\Python\AmzASINData.py", line 29, in
asind = catalog.get_catalog_item(asin='ASIN',includedData='relationships')
File "C:\Python\Python311\Lib\site-packages\sp_api\base\helpers.py", line 21, in wrapper
return function(*args, **kwargs)
File "C:\Python\Python311\Lib\site-packages\sp_api\api\catalog_items\catalog_items.py", line 93, in get_catalog_item
return self._request(fill_query_params(kwargs.pop('path'), asin), params=kwargs)
File "C:\Python\Python311\Lib\site-packages\sp_api\base\client.py", line 117, in _request
return self._check_response(res, res_no_data, bulk, wrap_list)
File "C:\Python\Python311\Lib\site-packages\sp_api\base\client.py", line 143, in _check_response
raise exception(error, headers=res.headers)
sp_api.base.exceptions.SellingApiBadRequestException: [{'code': 'InvalidInput', 'message': 'Request has missing or invalid parameters and cannot be parsed.', 'details': ''}]
To Reproduce
Steps to reproduce the behavior:
catalog = CatalogItems(credentials=credentials, marketplace=Marketplaces.IN)
asind = catalog.get_catalog_item(asin='ASINENTEREDMANUALLY',includedData='relationships')
the code works when trying to get summaries or salesRanks, but fails for relationship
Expected behavior
I expect the relationship data for asin to be shown. I have made sure the ASIN I am using has a parent or is a child and have tested both and multiple parents.
Desktop (please complete the following information):

OS: Windows. Using the lastest version of sp-api

Additional context
None.

Are you the ASINs brand owner? Certain included data properties are only available to them, not sure about relationships though. If you can, test it with an asin that belongs to your brand.
There's quite a few issues with those endpoints and included data to be found on google, so it seems like the error is known to Amazon, but hasn't been fixed in the past two years.
My best recommendation is to add the info you have to one of the open issues under Amazon's repository, or create a new one. The library itself doesn't alter request nor response - Amazon will have to do something to fix this, I can't unfortunately.

Yes, I am testing with ASIN for which I am the brand owner.
When I am using the service like boost.space and using the same credential I am able to get the relationships for the same ASIN. But the same credential and same ASIN gives the above error when using this library
I tested each parameter individually as per: https://developer-docs.amazon.com/sp-api/docs/catalog-items-api-v2022-04-01-use-case-guide
All these work: asin, attributes, dimensions, identifiers, images, productTypes, summaries
In this library however, instead of ranks, we have to use salesRanks - even that works.
vendorDetails - Special access is needed and shows foribidden error.
Only thing that doesn't work is relationships
I am not sure it is relevant, but this is a screenshot from boost.space using same credential and same ASIN and showing the response I am getting.

got it, that clears it. You are referencing the documentation for version 2022... but are using version 2020...
Try using the same version of the client as in the documentation, than it will work as expected, with the typing etc as in the relevant documentation.
To select a version for a client, use the version parameter in the client
 CatalogItems(credentials..., version=CatalogItemsVersion.V_2022_04_01)

Oh yes. That is it. https://developer-docs.amazon.com/sp-api/docs/catalog-items-api-v2020-12-01-use-case-guide
After using variation, the old code worked.
However, after adding version=CatalogItemsVersion.V_2022_04_01 I get the error access denied for all includedData, do I need to make any changes to use the new version.

I don't know your credentials nor access level. Once you've checked that according to the documentation you'll be good to go.

I don't know your credentials nor access level. Once you've checked that according to the documentation you'll be good to go.

@saleweaver can you please give us a bit clear idea about proper credentials and access level?
PS: getting the same problem

@rugved-bodke-stigya
No additional access level is required from Amazon.
The following code additional changes worked for me. I am not including the entire code, just the additional changes that worked for me.
from sp_api.api import CatalogItems, CatalogItemsVersion
catalog = CatalogItems(credentials=credentials, marketplace=Marketplaces.IN,version=CatalogItemsVersion.V_2022_04_01)
asind = catalog.get_catalog_item(asin='YOURASIN',includedData='relationships')

Thanks buddy, it actually works with specifying the version

Yes, but you also need to import CatalogItemsVersion as well


[TableRowColumn][Bug][Style] text-overflow ellipsis needs additional style condition

Problem description
The text-overflow: ellipsis condition is no longer applying the correct overflow style to text int he TableRowColumn component
Steps to reproduce
Create a Table with a TableRowColumn that has a small width and fill it with a very long string and you'll see that it doesn't overflow correctly
Versions

Material-UI:  0.16.0-rc1
React: 15.2.1
Browser: Chrome

Workaround + Fix
We will need to add overflow: hidden to the TableRowColumn style in https://github.com/callemall/material-ui/blob/master/src/Table/TableRowColumn.js
i.e.
Previous
root: {
      ...
      textOverflow: 'ellipsis',
    },

Proposed
root: {
      ...
      textOverflow: 'ellipsis',
      overflow: 'hidden',
    },

Happy to submit a PR for this minor fix.

Sadly this bug shipped in 0.16.0. It's not mentioned in the breaking changes for that release, so I guess nobody saw the issue.

+1

Duplicated of #5377 and fixed on #5378.


Repeated PushFront -> PopBack causes index out of range [-1]

This panics on the 65th iteration:
package main

import "github.com/ef-ds/deque"

func main() {
	q := deque.New()
	for {
		q.PushFront(1)
		q.PopBack()
	}
}

https://play.golang.org/p/CaG4fu1EY-E
I know that isn't the normal use, but I feel like it should work.

Many thanks @jrodatus for reporting the issue!


Create anagram.js

two strings are anagram or not

The problem could be with if (anagram(word1,word2)) on line 18, where word1 and word2 are undefined.

Sir, this was my first code that i had written to merge ...I do not have
any previous knowledge to pass test and all.I'm new to this help me out if
possible
On Sun, Sep 16, 2018 at 9:39 PM Ocn<EMAIL_ADDRESS>wrote:

The problem could be with if (anagram(word1,word2)) on line 18, where
word1 and word2 are undefined.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/trekhleb/javascript-algorithms/pull/182#issuecomment-421788812,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVNWjH2BOaMqHWNWjqicfznZIGeDF1w8ks5ubnfVgaJpZM4WODFu
.

@AnishTiwari No worries, the code was correct except for line 18, which should be:
if(anagram("binary", "brainy")){
You can delete line 24 as it is not used, and you may try to work on the indentation too.

changed it
On Mon, Sep 17, 2018 at 11:37 PM Ocn<EMAIL_ADDRESS>wrote:

@AnishTiwari https://github.com/AnishTiwari No worries, the code was
correct except for line 18, which should be:
if(anagram("binary", "brainy")){
You can delete line 24 as it is not used, and you may try to work on the
indentation too.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/trekhleb/javascript-algorithms/pull/182#issuecomment-422114077,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVNWjE_eQ1V5z23dKSw3qehhXtUs5GHXks5ub-TTgaJpZM4WODFu
.


Sscri

script/bootstrap does not work as planned on ubuntu.
I installed ubuntu and already ran the script, follow my command history.
sierra@SierraFidelize:~/.dotfiles/script$ history
    1  git clone https://github.com/ricardorsierra/dotfiles.git ~/.dotfiles
    2  sudo apt-get install git
    3  git clone https://github.com/ricardorsierra/dotfiles.git ~/.dotfiles
    4  cd ~/.dotfiles
    5  script/bootstrap
    6  cd script/
    7  ls
    8  vim bootstrap
    9  vi bootstrap
   10  vi install
   11  history

Segue Erro:
vi bootstrap
Error detected while processing /home/sierra/.vimrc:
line    1:
E319: Sorry, the command is not available in this version: syntax on
line    4:
E319: Sorry, the command is not available in this version: filetype indent plugin on
Press ENTER or type command to continue

I think you should use vim instead of vi.


Changes to behavior of user warnings

Codecov Report

Merging #31 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #31      +/-   ##
==========================================
- Coverage   72.33%   72.31%   -0.03%
==========================================
  Files           7        7
  Lines        1117     1116       -1
==========================================
- Hits          808      807       -1
  Misses        309      309

Impacted Files
Coverage Δ

hydrostats/data.py
52.52% <0%> (-0.48%)
:arrow_down:

hydrostats/analyze.py
75.58% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


Fix typo?

This is not a typo IMO.
Have you tested this change? is this PR solving an issue? can you expand on this ? Otherwise i'm inclined to not merge this.

Read docs now... This is like:
if (Boolean(recaptcha)) {
....
}
Sorry, my mistake.


Moving: Kingsoft.WPSOffice-CN version <IP_ADDRESS>38

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

To where?

To where?

Kingsoft.WPSOffice.CN


Bug reference file editing

IMPORTANT: Always create an issue before a PR and provide enough information so that others can review

Explain the details for making this change.
What existing problem does the pull request solve?

Test plan (required)
Demonstrate the code is solid.  Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.

Closing issues
List all issues this PR resolves

closes #644

Pre-Merge checklist
Complete these items before requesting reviews

[ ] Static Analysis Rules Validated
[ ] All commits follow naming conventions

Sub-tasks Checklist

[ ] UI Implementation
[ ] UI Test
[ ] Backend Implementation
[ ] Backend Tests
[ ] Integration Tests
[ ] System Tests
[ ] Documentation

superceeded by #677


Add BVNetwork.404Handler module to web.config transform

Installed v4.1.0 from NuGet and just spent a couple of hours wondering why I the gadget didn't show up in the Add Gadgets dialog in the dashboard. Finally I found out that I needed to add the module under the episerver.shell config section in web.config.
<episerver.shell>
  <protectedModules>
    <add name="BVNetwork.404Handler" />
  </protectedModules>
</episerver.shell>

This should at least be documented in the readme and preferably handled by the web.config transform.

Agreed!

Hm, I don't have that in my web.config. And I have the Gadget.


Fix flaky Playwright tests

Fixes

Fixes #3713 by @sarayourfriend
Fixes #3714 by @sarayourfriend
Description

This PR attempts to fix the flaky Storybook Playwright tests by adding waits or testing that a font request was sent after the menu button is clicked, to make sure the fonts are loaded before taking the snapshots.
I merged the sensitive results test fix into this PR since both PRs were failing the CI due to the other test failure (sensitive result fix was failing due to Storybook failure, and the Storybook fix was failing due to sensitive results failure).
Instead of going to the homepage, and making a new search to check that sensitive results were loaded, I added a check for sent API request with the sensitive parameter.
Testing Instructions

The CI should pass.
Checklist

[ ] My pull request has a descriptive title (not a vague title likeUpdate index.md).
[ ] My pull request targets the default branch of the repository (main) or a parent feature branch.
[ ] My commit messages follow best practices.
[ ] My code follows the established code style of the repository.
[ ] I added or updated tests for the changes I made (if applicable).
[ ] I added or updated documentation (if applicable).
[ ] I tried running the project locally and verified that there are no visible errors.
[ ] I ran the DAG documentation generator (if applicable).

Developer Certificate of Origin

Developer Certificate of Origin
Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

LGTM! I wonder if it's worth excluding fonts from the playwright test, or at least, excluding them from maybe all but one specific one? It feels like whack-a-mole if we're adding sleep to tests as they appear flaky, when I suppose any test could technically have suddenly-new flakiness due to font loading?

I think I understood why the font loading issue happens for the internal header in storybook. The first rendered element does not contain any text, only the mobile header with logo and a button. That's why we would only load the font after opening the modal, which does have some text.

I'll review the tests for similar situations.
And I still am not sure what happened to the filter button.