Limitation on password length?

I tried to use a 128 characters password on my Zulip profile. The password was accepted when I set it up, but then I was constantly getting rejected logins. I reset it three times via the 'forgot password' functionality.
When shortening it to 49 characters, it was accepted (like the 128 chards one) but then also functional (I could log in).
This would suggest a limit on the password length, which is a red light form a security perspective (there should be no limit because there is not reason for having one when the password is stored correctly). Is that the case?

Did you discuss this issue in the forum @wsw70?

@PawBud no I did not. Is it expected to raise a bug / issue in the community first before (or instead) of here?
If so I will move it there.

Well keep this issue open and go to the community page 😄

It would appear we set a maximum password length of 100 characters.
class RegistrationForm(forms.Form):
    MAX_PASSWORD_LENGTH = 100
    full_name = forms.CharField(max_length=UserProfile.MAX_NAME_LENGTH)
    # The required-ness of the password field gets overridden if it isn't
    # actually required for a realm
    password = forms.CharField(widget=forms.PasswordInput, max_length=MAX_PASSWORD_LENGTH)
    realm_subdomain = forms.CharField(max_length=Realm.MAX_REALM_SUBDOMAIN_LENGTH, required=False)

From https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#maximum-password-lengths:
Maximum Password Lengths
Some hashing algorithms such as Bcrypt have a maximum length for the input, which is 72 characters for most implementations (there are some reports that other implementations have lower maximum lengths, but none have been identified at the time of writing). Where Bcrypt is used, a maximum length of 64 characters should be enforced on the input, as this provides a sufficiently high limit, while still allowing for string termination issues and not revealing that the application uses Bcrypt.

Additionally, due to how computationally expensive modern hashing functions are, if a user can supply very long passwords then there is a potential denial of service vulnerability, such as the one published in Django in 2013.

In order to protect against both of these issues, a maximum password length should be enforced. This should be 64 characters for Bcrypt (due to limitations in the algorithm and implementations), and between 64 and 128 characters for other algorithms.

It seems like 100 characters is potentially reasonable; maybe 128 would feel more standard.  But I think there's still a bug here; the login and registration flows seem to be using a different truncation approach for too-long passwords (or something).  Needs investigation.

Thanks @timabbott for the response and the reminder about bcrypt (I was pre-hashing passwords in the implementation above 72 chars, which is a good or bad idea depending on the population and their passwords, but anyways).

It seems like 100 characters is potentially reasonable

It is. What is indeed problematic as you are saying  is that a >100 chars password is accepted but truncated - and that truncated version is then stored as the actual password. Which means that a check at login time will always fail for such passwords.

@zulipbot claim

On a sidenote, I've noticed that after I reset the password for a user in the development environment, if I try to reset it again the email containing the reset link won't be logged to http://localhost:9991/emails/. Is this intended?

The issue seems to lie here:
class LoggingSetPasswordForm(SetPasswordForm):
    def clean_new_password1(self) -> str:
        new_password = self.cleaned_data['new_password1']
        if not check_password_strength(new_password):
            # The frontend code tries to stop the user from submitting the form ...
            # but if the user bypasses that protection, this error code path will run.
            raise ValidationError(PASSWORD_TOO_WEAK_ERROR)

        return new_password

    def save(self, commit: bool=True) -> UserProfile:
        do_change_password(self.user, self.cleaned_data['new_password1'],
                           commit=commit)
        return self.user

Explanation:
There's nothing wrong with the registration form. It does its validation the way it's supposed to; so no one can set a password greater than MAX_PASSWORD_LENGTH when registering for a new account. When someone tries to reset their password we use the above form/class instead which is unaware of MAX_PASSWORD_LENGTH.
If you refer to https://github.com/django/django/blob/master/django/contrib/auth/forms.py#L329 it's clear that due to the lack of a max_length attribute in the new_password1 and new_password2 fields no length checking will be done whatsoever when using form.clean() or any of its variants let alone using the MAX_PASSWORD_LENGTH that we defined.
The simple way to fix this is to just do the check in clean_new_password1. But if we want to be more consistent and do things the "Django way", we should override the new_password1 and new_password2 fields in our LoggingSetPasswordForm class. I'll open a PR with the later now.

Django 1.4.8/1.5.4 limited passwords to 4096 bytes in response to the DoS vulnerability, but 1.4.9/1.5.5 lifted this limitation while fixing the PBKDF2 implementation to avoid rehashing the password on every iteration. Empirically, PBKDF2PasswordHasher and Argon2PasswordHasher can hash a gigabyte password in about 1 and 2 seconds, respectively. So if we’re thinking about changing the maximum, it would be fine to remove it entirely.

I think there's probably utility to having some limit on password length ; it feels like there's benefit for not having to reason about that category of DoS (and in any case, potentially an unauth user spending 1s of server-side resources could be a relevant DoS consideration).  So I think it's probably worth merging the fix to make our length checking logic consistent.  I'd be fine with increasing the max length to something plentiful for this application like 1024 bytes as a quick tweak as well.

To be clear, a user can’t actually transmit a gigabyte password; they’re limited by DATA_UPLOAD_MAX_MEMORY_SIZE (default 2.5 MiB, we customize it to 25 MiB). That was just a demonstration of the asymptotic behavior.
If a user is ever able to upload something that’s too big for us to hash, it’s probably already too big for us to store in memory, so we should be concerned about it well before the stage where we have a str that we can check the len() of.

I'm encountering this issue as well. Would be nice if an error message could be displayed that the password is too long.

@TornaxO7 Thanks for bringing attention back to this. I opened a newer issue at https://github.com/zulip/zulip/issues/27922 for fixing the user experience around this length limit


Upgrade the sample project from Swift 2.3 to Swift 3.1

@zezha-msft,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


[chores] Fixed regression tests #44

Fixed regression tests which were failing
on openwisp_controller because of poorly
setup url

Made map's urls dynamic

Closes #44

Coverage remained the same at 99.795% when pulling 4dc67385f532ec7f1210106aa1164c2ce65d2175 on issue-44-fixed-regression-tests into e9bc6eb1eacb88ecd7fcc90b172585057ba9e811 on master.

:smile: I knew it was a bad idea making django_loci aware of geo. It goes against the principle of orthogonality. Thanks @nemesisdesign I will fix this asap

Hey @NoumbissiValere,
Something went wrong with the build.
TravisCI finished with status errored, which means the build failed because of something unrelated to the tests, such as a problem with a dependency or the build process itself.
View build log
TravisBuddy Request Identifier: e3244870-158d-11eb-94fa-edf6748ec8ed


improved storm related tests and moved verification methods to testba…

…sespec

+1

I'll merge it myself


cannot search in different nix channels

hi, i've been using nix-search-cli for quite some time now and it's awesome for searching packages from the command line, but i wanted to try searching packages from the command line with sources from other channels but i didn't get anything
first i added new channel with this command
nix-channel --add https://channels.nixos.org/nixos-22.11-small nixos-22.11-small

and i update channel with this command
nix-channel --update

then i search package in this channel like this but i didn't get anything

Hi, glad to hear you're using and enjoying nix-search! This CLI program doesn't interact with your local channels at all; it only searches the Elasticsearch index that powers https://search.nixos.org/packages. The only valid values for --channel are unstable and whatever pinned version they have on the site, currently 24.05:

Sorry for the confusion!

I updated the cli help command to hopefully make this less confusing for the future:
# ... on a specific channel, default "unstable". The valid channel
#     values are what the search.nixos.org index has, check
#     that website to see what options they show in their interface.
nix-search --channel=unstable python3

No problem at all, thanks for writing in. If you have any other questions or suggestions, please let me know.


Can not use 'docker exec' in the docker while it is running

Hi,
I build a local version of jaeger by running the following commands.

./travis/build-all-in-one-image.sh
docker build –f cmd/standalone/Dockerfile –t <image_name> .
docker run -d -p5775:5775/udp -p6831:6831/udp -p6832:6832/udp   -p5778:5778 -p16686:16686 -p14268:14268 <image_name>

Everything works fine unto this point.
I want to see the logs in the jaeger server so I want to use the docker exec command to browse the container. I use the following command
docker exec -it <containerid>  bash
But I see the following error.

rpc error: code = 2 desc = oci runtime error: exec failed: container_linux.go:262: starting container process caused "exec: "bash": executable file not found in $PATH"

Thanks in advance.

because the base image has no tooling:
$ head -2 cmd/standalone/Dockerfile
FROM scratch

you can swap it for alpine when building your image.

Thanks @yurishkuro . It worked.


Add Community Bundle

Fixes #134.

Adds Community Bundle issue and pull request stats to the daily report and the circuitpython.org/contributing scripts.
For the circuitpython.org addition, the Community Bundle is not subjected to the infrastructure validators.
Mitigated some KeyError exceptions I was getting in validate_repo_state(). The GitHub API results were missing the license and permissions keys. I couldn't find anything regarding changes to the API, and the circuitpython.org Actions job doesn't seem affected. Were there some access restrictions made?

@tannewt done.


Scenario Image

I'm new to Valkyrie and I'm trying to choose a thumbnail image for the scenario.  I click "image" but it doesn't give me any choices.  I'm assuming I need to upload images somewhere (jpg, 200x200px) but no matter where I drag images they don't seem to show up here.

You have to change your quest.ini with a text editor
Have a look here:
https://github.com/NPBruce/valkyrie-questdata/blob/master/source/MoM/TheFallofHouseLynch/quest.ini
https://github.com/NPBruce/valkyrie-questdata/blob/master/source/MoM/TheFallofHouseLynch/hol.jpg

Thank you!
I believe that solved the problem, or at least got me a step closer to
fixing it.  My first problem was finding the quest.ini in the first place..
:)
On Tue, Jun 26, 2018 at 6:06 AM, redwolf2<EMAIL_ADDRESS>wrote:

You have to change your quest.ini with a text editor
Have a look here:
https://github.com/NPBruce/valkyrie-questdata/blob/master/source/MoM/
TheFallofHouseLynch/quest.ini
https://github.com/NPBruce/valkyrie-questdata/blob/master/source/MoM/
TheFallofHouseLynch/hol.jpg
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/NPBruce/valkyrie/issues/845#issuecomment-400268815,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AmtCILoZ9m9wKkB3tv4zNmBHot_dFuGBks5uAhWbgaJpZM4U3DJM
.

--
Thanks in advance for your time.
Steven E. Metze
512-496-0936
www.ubergoobergames.com

Logo images will only show you custom images.
Drop your 200x200 logo image in the scenario location:
%appdata%Valkyrie\MoM\Editor\Scenario1
If you are following the guide I've updated the page to detail the location, sorry I missed it:
https://docs.google.com/document/d/1Gi5gTwKkw84Px0Lvk-bJ3Aml_vF3ZoljjB6a8FjWGt8/edit

Once you've copied the file, when you click the box next to image it will show in the menu.

Excellent!  That worked perfectly, thanks!
On Tue, Jun 26, 2018 at 2:19 PM, scrubbless<EMAIL_ADDRESS>wrote:

Once you've copied the file, when you click the box next to image it will
show in the menu.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/NPBruce/valkyrie/issues/845#issuecomment-400431621,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AmtCIGdhujlvb_jEmOp32KfHNQ3ID4Kmks5uAok_gaJpZM4U3DJM
.

--
Thanks in advance for your time.
Steven E. Metze
512-496-0936
www.ubergoobergames.com


XRDP - gnome-session shows black background

Hi,
We are using XRDP to connect RHEL7 machine and KDE is working well but gnome having issue with black background.
could see the below log under "/home/asandh/.local/share/xrdp/xrdp-chansrv.35.log"
{code}
[20190528-12:59:59] [ERROR] X error BadWindow (invalid Window parameter) opcodes 18/0 resource 0xc0016c
[20190528-12:59:59] [ERROR] X error BadWindow (invalid Window parameter) opcodes 25/0 resource 0xc0016c
[20190528-12:59:59] [ERROR] X error BadWindow (invalid Window parameter) opcodes 18/0 resource 0xc00175
[20190528-13:00:00] [ERROR] X error BadWindow (invalid Window parameter) opcodes 25/0 resource 0xc00175
[20190528-13:00:00] [ERROR] X error BadWindow (invalid Window parameter) opcodes 18/0 resource 0xc00175
[20190528-13:00:00] [ERROR] X error BadWindow (invalid Window parameter) opcodes 25/0 resource 0xc00175
{code}
does this log gives you any idea about the issue.

If VNCServer is installed try uninstalling it.

This is pretty stale now, so I'm closing it. Feel free to open another issue if this is still a problem.


Add warning about discarded changes in unreadable objects

This is not related to a specific version, so can be merged asap
/cc @Adam-Dupaski


C_CPP : Moving from C to CPP

Description

This will help to learn CPP very easily if anybody knows C already.

Domain
C/CPP
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign

Can I work on this issue @Suvraneel?

@Kanishk0412  Its already been taken Kanishk..

I'm only Kanishk.

Okay no problem


Add configurable max GET request size in bytes attribute (close #449)

This PR addresses issues #449 and #362.
It adds the maxGetBytes configuration parameter that sets the maximum size for GET requests. The size in bytes is checked for the full GET request URL. In case requests are over this size limit, an error is written to console.log and the event is ignored (not added to queue).
The default behaviour remains that the request size for GET is unlimited.

Thanks for your pull request. Is this your first contribution to a Snowplow open source project? Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
:memo: Please visit https://docs.snowplowanalytics.com/docs/contributing/contributor-license-agreement/ to learn more and sign.
Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.


Support form_post OIDC response mode

Preflight Checklist

[X] I could not find a solution in the existing issues, docs, nor discussions
[X] I have joined the ZITADEL chat

Describe your problem
I was trying to setup Hocus on a local computer, and since I already use Zitadel for authentication for many other programs I host, I wanted to configure it to use my existing Zitadel self-hosted instance as its OIDC provider. However, after trying, it appears that Hocus uses id_token as its response type and form_post as its response mode. Using github search and looking through the Zitadel admin UI, I can see no way to enable form_post as a valid response mode, so I assume it isn't implemented anywhere. The only reference I can find is Apple's IDP implementation uses it, but that is for external OIDC, not OIDC handled by Zitadel.
Describe your ideal solution
The best solution to this would just be to implement form_post as a valid response mode in Zitadel OIDC applications, so applications can be configured to respond correctly to requests that ask for this response type. This would open up Zitadel to being used for both Hocus and any other programs that use form_post as their response mode.
Version
v2.42.10
Environment
Self-hosted
Additional Context
No response

hei @livio-a @muhlemmer what do you think about this?

The OpenID connect standard is this one: https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
Instead to sending a typical redirect to the client's callback we would respond with a html <form> that auto-submits to the token endpoint. The form data holds the same data as the redirected URL would.
Overall complexity would be low to implement in OIDC. However, I don't see this being high priority at the moment.
I will migrate this to the OIDC repository as it needs to be implemented there.


disentangle germline vs somatic molecular abnormalities

See also #3452.
compare:
id: MONDO:0043452
name: chromosome 8, trisomy
def: "A chromosomal abnormality consisting of the presence of a third copy of chromosome 8 in somatic cells." [NCIT:C36396]
synonym: "chromosome 8 duplication" RELATED [MESH:C537942]
synonym: "trisomy 8" EXACT [MESH:C537942, NCIT:C36396]
xref: MESH:C537942 {source="MONDO:equivalentTo"}
xref: NCIT:C36396 {source="MONDO:equivalentTo"}
xref: SCTID:205649008 {source="MONDO:equivalentTo"}
xref: UMLS:C0432412 {source="NCIT:C36396", source="MONDO:notFoundInDiseaseSubset"}
is_a: MONDO:0020050 {source="NCIT:C36396"} ! autosomal trisomy

id: MONDO:0016526
name: trisomy 9p
def: "Trisomy 9p is a rare chromosomal anomaly syndrome, resulting from a partial or complete trisomy of the short arm of chromosome 9, with a wide phenotypic variablility, typically characterized by intellectual disability, craniofacial dysmorphism (e.g. microcephaly, large anterior fontanel, hypertelorism, strabismus, downslanting palpebral fissures, malformed, low-set, protruding ears, bulbous nose, macrostomia, down-turned corners of mouth, micrognathia), digital anomalies (brachydactyly and clinodactyly), and short stature. Less frequently patients present with cardiopathy and renal, skeletal, and central nervous system malformations." [Orphanet:236]
subset: ordo_malformation_syndrome {source="Orphanet:236"}
synonym: "Duplication 9p" EXACT [Orphanet:236]
synonym: "Duplication of the short arm of chromosome 9" EXACT [Orphanet:236]
synonym: "trisomy of the short arm of chromosome 9" EXACT [Orphanet:236]
synonym: "trisomy type 9p" EXACT [MONDORULE:4, Orphanet:236]
xref: ICD10:Q92.2 {source="Orphanet:236", source="ORDO:236/attributed", source="ORDO:236/ntbt"}
xref: Orphanet:236 {source="MONDO:equivalentTo"}
xref: UMLS:C0265428 {source="Orphanet:236", source="MONDO:equivalentTo"}
is_a: MONDO:0016946 {source="Orphanet:236"} ! partial trisomy of the short arm of chromosome 9

(yes I know 8 != 9 just picked random two examples to illustrate a point)
the label for the former doesn't say anything about it being somatic, but by the definition it is
The latter is pretty well implicitly germline or at least early somatic
to further confse, the NCIT xref is not to a disease but to a shadow branch:

we need to disentangle germline vs somatic, disease vs chromosomal feature

FYI, the definition of MESH:C537942 {source="MONDO:equivalentTo"} does not include somatic.
A condition caused by an extra copy of chromosome 8. The effects can vary from normal development in some individuals, to facial, growth, and limb abnromalities, as well as delayed speech and intellectual disability. Trisomy 8 may also cause kidney, heart, and bone abnormalities.
Date introduced: August 25, 2010

@sabrinatoro will work on this after finishing chromosomal anomaly remodeling

We should also look to importing the NCIT molecular abnormality branch to axiomatize cancer subtypes


Web - Chat - Email address is superimposed with user's avatar when the mouse clicks on the chat's name

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

Action Performed:

Go to URL https://staging.new.expensify.com/
Login with any account
Go to any chat
Hover the mouse cursor over the chat username

Expected Result:
Email address shouldn't be superimposed with the user's avatar
Actual Result:
Email address is superimposed with user's avatar
Workaround:
Unknown
Platform:

Where is this issue occurring?

Web

Version Number: <IP_ADDRESS>
Reproducible in staging?: Yes
Reproducible in production?: Yes
Email or phone of affected tester (no customers): any
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

https://user-images.githubusercontent.com/93399543/200095241-1c67b071-292c-404b-9eb6-1a5412b975f9.mp4
Expensify/Expensify Issue URL:
Issue reported by: Applause - Internal Team
Slack conversation:
View all open jobs on GitHub

Reproducible and doesn't seem to be a duplicate - moving forward

Proposal
Remove imported <Tooltip /> components in avatar's component or make a condition in avatar's component if it used by another page with tooltip required
https://github.com/Expensify/App/blob/91acada3b65af8c465febe6853bcc7d37995f0f4/src/components/MultipleAvatars.js#L58-L128
https://user-images.githubusercontent.com/85979206/200521258-8f64d08c-1caf-42b8-bbd5-dae923c16ef9.mov

I don't think this is a bug. we can increase the space between the tooltip and the report title on the header so that it does not lay over the avatar but that feels unnecessary. Tooltips can lay over anything, it does not create a issue for the user.
@Expensify/design Any inputs?

Yeah I agree, I don't think this one is a bug.

Going to close this out!


Adding type field to TrackView

Though it's declared as optional in integration doc for v4, it's already used(if supported by wrapper) by peer-agent. hlsjs-p2p-wrapper implemented this(type is hardcoded to video) already, now it's dashjs-p2p-wrapper turn.
For example:

Here https://github.com/streamroot/peer-agent/blob/dev/app/js/p2p/SRModule.js#L111.
Here https://github.com/streamroot/peer-agent/blob/dev/app/js/p2p/stats/MediaStats.js#L29.

@jlouazel yup, but a bit later ;)


[SC-619] Hardhat ethers tests migration

Codecov Report
Base: 79.59% // Head: 79.28% // Decreases project coverage by -0.31% :warning:

Coverage data is based on head (684c92c) compared to base (c3cfd31).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff             @@
##           master      #45      +/-   ##
==========================================
- Coverage   79.59%   79.28%   -0.32%
==========================================
  Files          24       24
  Lines         642      642
  Branches      112      138      +26
==========================================
- Hits          511      509       -2
- Misses        131      133       +2

Impacted Files
Coverage Δ

contracts/oracles/DodoV2Oracle.sol
95.23% <0.00%> (-4.77%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


ARM Docker support

I managed to update everything, such that it now builds for both linux/amd64 and linux/arm64.
The packages built using the updated files can be seen and tested from here:
https://github.com/BE-CH/umami-arm-platform-support/pkgs/container/umami
Changes

Uses v6 of mr-smithers-excellent/docker-build-push that has support for buildx and therefore multi-platforms
Added network-timeout to Dockerfile yarn, to combat some issues with packages timing out due to slow CPU when github actions
Updated node to v18 in the Dockerfile
Updated Prisma to  v4.11.0 to use the linux/arm64 prebuilt binaries.

Keep in mind it took my Github Actions 21 minutes and 33 seconds to build the images. Just for a reference if you feel like its stuck building.

✅ Successfully builds and publishes.
We should consider updating some of our dependencies, such as node, postgres etc.
@mikecao

@benricok Thanks for the review! :)
Who can authorize this on vercel, so we can get it in master? @mikecao

Why does it take so long to build? Which step is taking the longest?

Why does it take so long to build? Which step is taking the longest?

@mikecao The main reason why it takes so long to build, is due to buildx that uses QEMU to simulate the different platforms. This is usually quite heavy on low end machines like Github Actions are running on.
Furthermore, it is important to remember that it has to do the entire build process for each platform. In our case this essentially doubles the build time.
This is tho, as expected when building for multiple platforms on low end hardware like Github Actions.
The below are the most time consuming steps:
#21 [linux/amd64 deps 6/6] RUN yarn install --frozen-lockfile ~ 127 seconds
#27 [linux/arm64 deps 6/6] RUN yarn install --frozen-lockfile ~ 475 seconds
#30 [linux/amd64 builder 5/5] RUN yarn build-docker ~ 101 seconds
#40 [linux/arm64 builder 5/5] RUN yarn build-docker ~ 729 seconds

@mikecao Please either create a new release or manually trigger the action to build the ARM64 images...


Fix mocha tests

As discussed in #456 mocha tests are currently failing/hanging in Travis CI. I've also observed this behavior on my local machine.
Reason appears to be that the previously used version of mocha-phantomjs doesn't support phantomjs 2.x. It looks like Travis CI now uses phantomjs 2.x by default, hence these issues.
This PR upgrades mocha-phantomjs to latest version and also upgrades mocha to the latest version as the previously used version (not sure which version that was?) was not supported by this new version of mocha-phantomjs.
It's worth pointing out that this new version of mocha-phantomjs supports phantomjs 2.x, but includes version 1.9.7 which doesn't run on MacOS Sierra. To run the mocha specs on Sierra the following command can be used to run with a phantomjs version in your path: mocha-phantomjs -p $(which phantomjs) http://localhost:4567/test.

Thank you @pascalw !


A way to force controller usage, i.e. ignoring hand tracking?

Discussed in https://github.com/maluoi/StereoKit/discussions/363

Originally posted by paulmelis April 26, 2022
I'm getting less and less enthousiastic with the hand tracking on our XR-3, especially for demos by VR novices it really doesn't work very well. I searched for a flag in SK to ignore native hand tracking and use detected controllers instead, but I suspect such a flag isn't currently available?

There is not currently, but that sounds like a good feature to have!

This may get a more 1st class resolution in an upcoming interaction refactor, but in the meantime, a solid answer here would be to add this line before SK.Initialize:
Backend.OpenXR.ExcludeExt("XR_EXT_hand_tracking");


Support more bundling options

Adds support for ES3, ES5, and ESNext bundling

Available formats are now following https://get.grammy.dev/es<ES version>@<grammY version>.js.
Examples:
1.0 release in ES3<EMAIL_ADDRESS>Current stable in ES6<EMAIL_ADDRESS>Current HEAD in ESNext<EMAIL_ADDRESS>

Actually, ES3 and ES5 bundling does not make any sense, and these versions have never worked for anyone. Internally, grammY uses a Proxy instance for every single API request, which only exists since ES6. It makes no sense at all to provide those old versions.


added google assistant

Closes #8173

Relates to #XXXX

[ x ] I have read the Contributing Guide.

It might be possible to extract the installer, instead of running it. Can you try it?

Please create the PR from a new branch other than master

Closing because of unrelated changes...

@rashil2000 will create a new one, not called master. What do you mean by extracting the installer instead of running it?


Filter all unscheduled tasks (TODOs)

Does this feature exist in Emacs orgmode core?
Yes
Orgmode link
According to the following StackExchange thread it should be possible:
How do I view all org-mode TODOs that are not recurring, or not scheduled?
Feature value
It would be nice, if I could display all TODOs which are so fare not scheduled. I tried to use advanced search but I was not able to filter them out.
Additional context
No response

As i see from the link you attached, this requires custom agenda view. You can follow that on #135 .

:+1: for this - currently I set dates arbitrarily just to have items show up in the agenda.


Remove ExtenedMap, ToggleSet, and observable versions

Switch to helper functions instead. They don't impact the prototype
tree and it means that we don't need to introduce versions that are
both observable and "normal"

Tidy  and hiddenTableColumns to not need
pre-initialization

Signed-off-by: Sebastian Malton<EMAIL_ADDRESS>

@jim-docker Probably not, I wanted to use this in a different PR... but I will move this to 5.3.1 instead.

Seeing this, though probably not related to changes in this PR?

Did you notice what the console error was too?

That sounds like you unloaded the lenscloud extension but were still viewing the ManagedDevCluster category

So yes, not related to this PR.

@jim-docker PTALA


Fp-api with "with-*" pattern

Qrizzly's request is here!
Here's a short example:

    let store = new SqlStreamStore.InMemoryStreamStore()

    let caseMessages =
        SController.init store "Case::1"
        |> With.prefetch
        |> With.messageCount 200
        |> With.readVersion ReadVersion.Any
        |> SMessage.messages

Can be found here

Not sure why With as a module was needed but.. Looks good =)

Not sure why With as a module was needed but.. Looks good =)

To know which optional params you can supply. Keeping them in with makes it easy to dot-discover the options that you have.
Hmm dot-discover I like this word.. I should use it more often🤣

Question from a C# perspective:
You have classes in which every method is abstract, should you use interfaces instead? Not sure about the implications in F#.

Question from a C# perspective:
You have classes in which every method is abstract, should you use interfaces instead? Not sure about the implications in F#.

I'm using those as interfaces :P Basically I didn't spend much time to learn how interfaces work in F#. There is some weird parts. Abstract classes however, worked as I anticipated right away, and I'm using them as a way to define an interface rather that lift up functionality as one would normally do.
If I end up using the FP approach all of those files will disappear anyways :P

Abstract classes are more limited, you can only implement one class at a time etc. If they "disappear anyways" it doesn't matter, otherwise interface are better


Create Minimal Soulbound Token smart contract (EIP-5484)

We want to start issuing Soulbound Tokens to users.
Implement a basic smart contract based on EIP-5192: Minimal Soulbound NFTs.
It must extend ERC721Metadata as per EIP 721.
Call the smart contract Soulbound-NFT and deploy to MATIC Mumbai testnet for testing.
This issue is for a basic MVP. The more detailed requirements will come later.

Questions regarding Solbound-NFT.

What will be the mint price? Anyone can mint freely?
Do we mint NFT to Verida account or general Wallet account?
I think, we should mint NFT to Verdia account. In case, we need signature verification step on minting.
If we mint NFTs to Verida account, we should override many functions of original ERC721 contract. We should add signature verification to functions.
Is there any limits to NFT counts? A user can owe only one NFT or more?

Great questions @ITStar10.
NFT mint permission
Users can mint their own NFTs, however they will need to provide a proof to mint the NFT. We will need to add the verification base contract capabilities to this NFT contract. I need to write up a scoping document for this.
Basically; A user will provide a proof of something off-chain that allows them to mint a NFT.  Anyone can mint freely?

No mint price, anyone can mint.

Do we mint NFT to Verida account or general Wallet account?

NFT's will be minted to the user's Wallet account.

I think, we should mint NFT to Verdia account. In case, we need signature verification step on minting.

Why do you think we should mint NFT to Verida account?

If we mint NFTs to Verida account, we should override many functions of original ERC721 contract. We should add signature verification to functions.

Is there any limits to NFT counts? A user can own only one NFT or more?

There are no limits.

Example flow

User signs into their Twitter account and authorizes a Verida server to gain an access token
Verida server generates a proof string (twitter-${twitterId}-${did}) and signs it using a Verida Company DID that represents a "trusted signer" on the Verida network
Verida server sends the signed proof to the User, who stores it in their Vault
The user clicks a claim button in the Vault to claim a SBT
The user sends the signed proof to the SBT smart contract, with a wallet address, along with a signature that combines the contract params and a nonce (using the Verida Verification Base process)
The NFT uses the Verida Verification Base smart contract library to verify the signature, verify the signed proof matches the Verida Company DID and then mints an NFT for the user's crypto wallet
A user receives a NFT in their requested wallet address
A SBT can only be claimed once per wallet, per SBT type

SBT types

twitter-account
facebook-account
linkedin-account

Requirements

Support adding / removing Verida company DIDs (owner only)
Support adding / removing (owner only)
Support a claimSbt() function


Optional dynamic middleware file added

This is a feature I use constantly in my applications, but it only works in Laravel 5.1 because of the new feature, middleware parameters.
To use, register middleware in your
Http\Kernel.php:
protected $routeMiddleware = [
    // …
    'can' => 'Caffeinated\Shinobi\Middleware\UserHasPermission',
    // …
];

…then in your controller (or routes), call with the required permission
name:
public function __construct()
{
    $this->middleware('can:permission_name’);
}

Just noticed the header status codes are inconsistent.  I think like they should both be 401, so I'm going to fix this.


Soul Glass

Smelt soul sand into soul glass?

Not a dumb, like it.
Glass will be black-ish, maybe with some sort of soul like something... No frame, and blocks light.

For balance, might need to combine soul sand with something else to craft this, will see how it plays out.


PopUp New Phone Number records

[x] The NUMBER field should be mandatory. Include a red asterisk to denote this property.
[x] The EXTENSION must be optional.
[x] The TYPE field must be a drop-down menu, the App_Aux_field must be filtered to "PhoneType"
[x] The TYPE should be optional to
[x] The DATE is not selectable, must use the timestamp, in fact this might be invisible. In the database is configured to use CURRENT_TIMESTAMP function.
[x] The STATUS checkbox must be activated by default. This way every new phone record is an active record until the user set it the other way.

This task is done please take a look at it.

I can't edit records... can we do that clicking directly on the phone number?

The Edit Function is done

Looks Good


Support for nvim-notify

Would be nice to add support for nvim-notify. The documentation mentions all the highlight groups used.

#81

#81


git: include info documentation in doc output

Description of changes
Including gitman.info, which is not broken (anymore?) and is useful.
Motivated by Magit:
https://magit.vc/manual/magit/How-to-install-the-gitman-info-manual_003f.html
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
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

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

[X] Fits CONTRIBUTING.md.

This PR causes a massive rebuild, please use target branch staging.

Sorry, I guess that was the effect of pushing a version rebased on staging before changing the target branch in the Github UI...

We probably don't want to include those four copied commits in the history...


AZ command not found

I've followed the instructions listed @ https://docs.microsoft.com/en-us/cli/azure/install-azure-cli-apt?view=azure-cli-latest but getting the following error after executing 2nd sudo command -
sudo apt-get install apt-transport-https
Error:
"E: Malformed Entry 1 in the list file /etc/apt/source.list.d/azure-cli.list(component)
E: The list of sources could not be read

Environment summary
Using VM Ubuntu 1604LTS on Azure

Provide more details:
What are the contents of the file?
You can delete the file and recreate it.

Closing due to inactivity.

Change the line
RUN apt-get -y install apt-transport-https

To
RUN apt-get update && apt-get -y install apt-transport-https curl

For more details:
https://github.com/raintank/raintank-docker/issues/72

Problem when installing with different versions of Debian distro occurs, like "jessie".
What worked for me. Change the following line
echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ $AZ_REPO main" | \
     sudo tee /etc/apt/sources.list.d/azure-cli.list

to
echo "deb [arch=amd64] https://packages.microsoft.com/repos/azure-cli/ wheezy main" | \
     sudo tee /etc/apt/sources.list.d/azure-cli.list

Essentially we are telling the source file, to use a lower version of Linux Distribution for installing https.

Jessie is supported and has been for a few releases now. You can replace wheezy with jessie then update the package.

Really, @derekbekoe? He waited a full day for you: you could have waited at least that long before closing this - not to mention that you could have answered the question first. What's the big deal in leaving these tickets open? Do you get paid by the how many you close, or what? Do you get money deducted from your salary if they aren't closed? Enlighten me, please.


How to determine file size of incoming file before downloading?

[Enter feedback here]
It's not clear from the sample flow how the size of the incoming attachment (that is sought to be downloaded) will come from ?  The provided JSON snippet  does not have this size.  However, when the consent card is sent to the user in the example, the file size is sent?   How will the bot know the size of the file?
Teams now permits files of up to 250GB. Without a way to determine the file size before downloading,  , this could easily swamp the bot and lead to denial of service.
To clarify, The message activity example does not include the size (while the consent card JSON shows the file size hard coded)
{   "attachments": [{     "contentType": "application/vnd.microsoft.teams.file.download.info",     "contentUrl": "https://contoso.sharepoint.com/personal/johnadams_contoso_com/Documents/Applications/file_example.txt",     "name": "file_example.txt",     "content": {       "downloadUrl" : "https://download.link",       "uniqueId": "1150D938-8870-4044-9F2C-5BBDEBA70C9D",       "fileType": "txt",       "etag": "123"     }   }] }
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 4b69599c-1da4-8689-fd0c-4e4d8a348496
Version Independent ID: 872fa9a2-0543-4a94-5416-6e6dc389f0d0
Content: Sending and receiving files from a bot - Teams
Content Source: msteams-platform/resources/bot-v3/bots-files.md
Product: msteams
GitHub Login: @surbhigupta
Microsoft Alias: lajanuar

Hello @GauravES,
I am looking into it. I will update you soon.
Thanks

@GauravES - When we download the file, we generally get the response having content and size. But before even downloading, there doesn't seem to be any way to get it.

This was tagged as needing Author feedback.  What information can I provide?   This seems to be missing functionality?

Removed the tag


Cache performance will degrade in some simulator due to the implement of module "cache_lru"

Recently I have managed to port the Nyuzi to Xilinx ZC706 evaluation board and run doom & quakeview successfully, with respect. But during this process, I noticed a cache performance degradation when debugging with Modelsim SE 10.5c. Since such degradation seems only existing when simulating in some simulators and doesn't exist in verilator or after synthesize, I think maybe this topic is more like a portability suggestion than an issue.
When running the core on some simulators such as Modelsim, the x value coming from uninitialized SRAM will cause the casez statement in module cache_lru fail to match any pattern, further cause that in all cache set only way 0 is available. To illustrate it clearly, here is a piece of code snipping from cache_lru.sv when parameter NUM_WAYS is 4.
...

#130            4:
#131            begin
#132                always_comb
#133                begin
#134                    casez (lru_flags)
#135                        3'b00?: fill_way = 0;
#136                        3'b10?: fill_way = 1;
#137                        3'b?10: fill_way = 2;
#138                        3'b?11: fill_way = 3;
#139                        default: fill_way = '0;
#140                    endcase
#141                end
#142
#143                always_comb
#144                begin
#145                    case (new_mru)
#146                        2'd0: update_flags = {2'b11, lru_flags[0]};
#147                        2'd1: update_flags = {2'b01, lru_flags[0]};
#148                        2'd2: update_flags = {lru_flags[2], 2'b01};
#149                        2'd3: update_flags = {lru_flags[2], 2'b00};
#150                        default: update_flags = '0;
#151                    endcase
#152                end
#153            end

...

Consider after reset, two or more cache fill operations happened in the same cache set. When the first fill request comes, because the value of "lru_flags" is 3'bxxx (the value of uninitialized SRAM), the default branch will take effect, way 0 got filled, and the "update_flags" will be 3'b11x. Then, in the subsequent request handling process, the casez statement will always fail to match any pattern with the value of "lru_flags" (3'b11x), the default branch will always take effect, way 0 will always get filled, and "update_flags" will always be 3'b11x. The similar issue also exists when NUM_WAY is 8. The marked red area in the waveform generated by Modelsim attached below shows such situation:

Although it sounds like a bad idea, one solution to this problem is changing all casez in cache_lru.sv to casex. I made an experiment to estimate the performance impact: Some logic was inserted into the writeback_stage firstly to trace the function activity. Then, the same program got executed on two different designs, the original design and the design with modified cache_lru, for a given time. Since the program is same, the amount of log generated during simulation is related to the instructions got executed. By comparing the number of function tracing record, we can compare the performance approximately. The screenshot below shows the result: The design with modified cache_lru produced 2.8x more log than the original one, which can roughly be considered as running faster 2.8x.

The version I use is ce221ff, but this issue still exists in the latest version.
Finally, Thanks for bringing such interesting project!

Good catch! Nice write up of the issue too, thanks.
Since Verilator is only a two-state simulator (no x or z), it doesn't manifest this problem, but any four-state simulator probably will. Another solution might be to initialize the SRAMs to 0 at startup.

This patch should address the issue, but feel free to let me know if not.

Sadly, if a logic/reg variable is driven in an always_ff block, the "vlog" compiler in the latest Modelsim seems doesn't allow any other block drive that single again, even it's an initial block. So the patch 7780328 just can't pass the compile.

The following patch is ok with the help of macro SIMULATION, but not very beautiful...
--- sram_1r1w_ce221ff.sv        2017-03-23 23:05:54.677195800 +0800
+++ sram_1r1w_patched.sv        2017-05-05 16:32:46.063266600 +0800
@@ -100,7 +100,11 @@
     // Simulation
     logic[DATA_WIDTH - 1:0] data[SIZE];

+`ifdef SIMULATION
+    always @(posedge clk)
+`else
     always_ff @(posedge clk)
+`endif
     begin
         if (write_en)
             data[write_addr] <= write_data;
@@ -120,6 +124,11 @@

     initial
     begin
+`ifdef SIMULATION
+        for (int i = 0; i < SIZE; i++)
+            data[i] = '0;
+`endif
+
         if ($test$plusargs("dumpmems") != 0)
             $display("sram1r1w %d %d", DATA_WIDTH, SIZE);
     end

--- sram_2r1w_ce221ff.sv        2017-03-22 23:48:00.614532400 +0800
+++ sram_2r1w_patched.sv        2017-05-05 16:32:48.783422200 +0800
@@ -128,7 +128,11 @@
     // Simulation
     logic[DATA_WIDTH - 1:0] data[SIZE];

+`ifdef SIMULATION
+    always @(posedge clk)
+`else
     always_ff @(posedge clk)
+`endif
     begin
         if (write_en)
             data[write_addr] <= write_data;
@@ -160,6 +164,11 @@

     initial
     begin
+`ifdef SIMULATION
+        for (int i = 0; i < SIZE; i++)
+            data[i] = '0;
+`endif
+
         if ($test$plusargs("dumpmems") != 0)
             $display("sram2r1w %d %d", DATA_WIDTH, SIZE);
     end

Yeah, a bit hacky, but I'm not sure of another way to do this cleanly now. Pushed another patch.
I didn't add the SIMULATION guards in this patch. Did you need that because you are inferring the SRAM for the Xilinx part in that block? I would have expected the last block to not infer SRAMs properly (with an area and clock speed hit), but perhaps this works okay on Xilinx.  It definitely doesn't on Altera. I think it might be preferable to have a VENDOR_XILINX block and explicitly instantiate the block RAM, like how it is done in VENDOR_ALTERA, to avoid any issues.

Problem solved with 77a50a8, thanks for the time!
Yes, currently the SRAM in my design is inferred from this block because it just works... Thanks for the advice. I will make a VENDOR_XILINX block and submit another pull request after finished.


Question about Debiased Inbatch Loss

The explicit frequency calculation in the code is equal to the number of occurrences divided by the sum of the number of items in the training set, which is a number less than 1. After taking the log, it is a negative number, and after subtracting this negative number, the logits become bigger. Is this a misunderstanding on my part? If yes can you explain how this place works?
If the logits are calculated on all items, but the training set contains only some of the items, are the debias_logits of the items that do not appear in the training set set set to 0?

The debiased in-batch loss assigns lower weight to more frequent items and higher weight to less frequent ones. For detailed explanations, see: 1) XIR; 2) Google Debias.

It seems correct, but I'm unsure if the count is from the training set or the entire dataset. You can check the code for clarification.


Cannot add  spot near geolocate point

https://user-images.githubusercontent.com/9283127/105617874-970c0100-5da7-11eb-9d19-5bf44d58b4e5.mov

Maybe we should have a button that just adds a spot to the current location, like the shortcuts add the spot to the current location with a sample or measurement.

Maybe we should have a button that just adds a spot to the current location, like the shortcuts add the spot to the current location with a sample or measurement.

@nicolasmroberts where should I add a button to add a spot to current location?

@nicolasmroberts where should I add a button to add a spot to current location?


Remove deprecated 'bottle :unneeded'

Fixes https://github.com/Azure/homebrew-functions/issues/89
Formula parameter bottle :unneeded has been deprecated.
https://github.com/Homebrew/brew/commit/f65d525
https://github.com/Homebrew/brew/pull/11239

@rasmusbe Is there anything else needed to merge?

Anything holding up the merge? These deprecation warnings are getting annoying.

Warning: Calling bottle :unneeded is deprecated! There is no replacement.
Please report this issue to the azure/functions tap (not Homebrew/brew or Homebrew/core):
/usr/local/Homebrew/Library/Taps/azure/homebrew-functions/Formula/azure-functions-core-tools@3.rb:10

Sorry for the delay on this folks and @Ketouem thanks for the fix!


Create a base ember-twiddle for showcasing issues

As suggested in https://github.com/offirgolan/ember-light-table/pull/441#discussion_r123591773
An official base ember-twiddle would be super useful to quickly prototype new ideas or demonstrate bugs / issues.

Should we include any other addons by default? Good candidates:

ember-concurrency
ember-cli-mirage (what about pre-configuring it?)
ember-one-way-controls
ember-truth-helpers
ember-composable-helpers

Should we provide multiple routes with different base setups (similar to the dummy app) or only the one "classic" minimal example?
What about styling?
Should we include instructions in the twiddle itself? If so, which?

I think a good setup would just be a twiddle with ember-light-table with a basic table and simple data. We shouldnt depend on all those extra dependencies since they could potentially introduce some complications in the future (prolly not but hey... you never know). The more vanilla the easier it will be for us to debug 😄

I think a good setup would just be a twiddle with ember-light-table with a basic table and simple data.

By "simple data" you probably mean static fixtures (const rows = [ ... ]) and not a pre-configured Mirage?
I believe including Mirage is a good idea, because users tend to encounter problems while actually interacting with an API / Ember Data with #423 and #272 being examples. Setting up Mirage in Ember Twiddle is a pain we can alleviate. Here's the Mirage boilerplate Twiddle.
I understand that you want to keep the base Twiddle as slim as possible, so a second Twiddle with Mirage pre-installed could be a nice addition.

Very true! ELT + Mirage twiddle sounds good to me.
On Tue, Jun 27, 2017 at 12:24 AM Jan Buschtöns<EMAIL_ADDRESS>wrote:

I think a good setup would just be a twiddle with ember-light-table with a
basic table and simple data.
By "simple data" you probably mean static fixtures (const rows = [ ... ])
and not a pre-configured Mirage?
I believe including Mirage is a good idea, because users tend to encounter
problems while actually interacting with an API / Ember Data with #423
https://github.com/offirgolan/ember-light-table/issues/423 and #272
https://github.com/offirgolan/ember-light-table/issues/272 being
examples. Setting up Mirage in Ember Twiddle is a pain we can alleviate.
Here's the Mirage boilerplate Twiddle
https://ember-twiddle.com/eedfd390d8394d54d5bfd0ed988a5d0f?openFiles=twiddle.json
.
I understand that you want to keep the base Twiddle as slim as possible,
so a second Twiddle with Mirage pre-installed could be a nice addition.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/offirgolan/ember-light-table/issues/442#issuecomment-311275417,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAjJwo0BHZzpsLDqvjtJ2juX5DvlQaMpks5sIK4YgaJpZM4OCzBQ
.

--
Thanks,
Offir Golan


Handling of error in playback

Hi Dave,
We've come across an issue when doing an immediate answer and playback in certain scenarios:
TypeError: Cannot read property 'getHeader' of undefined
    at /opt/voice-core/node_modules/drachtio-fsmrf/lib/endpoint.js:322:36
    at __x (/opt/voice-core/node_modules/drachtio-fsmrf/lib/endpoint.js:902:31)
    at Endpoint.execute (/opt/voice-core/node_modules/drachtio-fsmrf/lib/endpoint.js:910:7)
    at Endpoint.sendPlay (/opt/voice-core/node_modules/drachtio-fsmrf/lib/endpoint.js:320:16)
    at fn (/opt/voice-core/node_modules/async/lib/async.js:746:34)
    at /opt/voice-core/node_modules/async/lib/async.js:1213:16
    at /opt/voice-core/node_modules/async/lib/async.js:166:37
    at /opt/voice-core/node_modules/async/lib/async.js:706:43
    at /opt/voice-core/node_modules/async/lib/async.js:167:37
    at Immediate.<anonymous> (/opt/voice-core/node_modules/async/lib/async.js:1206:34)
    at runCallback (timers.js:705:18)
    at tryOnImmediate (timers.js:676:5)
    at processImmediate (timers.js:658:5)
    at process.topLevelDomainCallback (domain.js:126:23)

Looking over the relevant line, it appears an err object is expected but not dealt with.
I don't know a lot of the conventions used in the drachtio libs, however I believe this should be sufficient as a patch?

Thanks!


Async child components are created after App.vue mounted() on client but not on SSR

Version
3.1.6
Reproduction link
https://codesandbox.io/s/fervent-dream-5upjy
Steps to reproduce
Run the code and check the console output of the SSR and the Client hydration.
What is expected?
I'm using Quasar with SSR mode, but we have trouble there with async components. We run into some errors because at the SSR side some components are created, which on the client side are created after the initial mount. This in turn causes hydration errors. In the provided example I have a MainLayout (which is async loaded in the router), which in turn  loads (also async) an EssentialLink component. In order to solve our issue this EssentialLink component should be created on the client side before the App.vue mounted hook.
What is actually happening?
Currently only the component loaded async in the route itself is created before App.vue mounted(). Child components that are also async are created after the App.vue mounted() hook which causes issues for us.

Server and client side are waiting for router.onReady() which in the documentation says that async components are resolved before this hook is called: https://router.vuejs.org/api/#router-onready.
It seems to me that the router.onReady() should only be fired when all async child components are also resolved and created.

When reporting a bug we need a boiled down repro to check (only vue and vue router).

Currently only the component loaded async in the route itself is created before App.vue mounted(). Child components that are also async are created after the App.vue mounted() hook

The onReady hook resolves after the initial navigation, which means after async route components have resolved. Other async component will resolve later, upon mounting. The explanation regarding hydration at https://ssr.vuejs.org/guide/routing.html#code-splitting should make more sense

Ok, is it impossible to make wait for other async components or is it a design choice? In our case hydration errors occur because of this, and I'm just trying to get a clear picture where we need to be to fix this.


Include SSO automatically as part of Calendar skill integration with VA

As a user I want to be able to access the skills without having to login again inside chat window. Currently, after integrating with VA, I have to click login button, and copy paste a Code to continue flow.
Acceptance:
User says "Create new meeting at 7PM" automatically skill is invoked and flow continues

There would be new calendar experience with VA scaler core. Close this issue for now.


6.4.0rc3

What's New?

Move some selectors into util files to make them easier to test.
Tests for setActiveSequenceByName
Remove legacy RESOURCE_INIT handler in sequencesReducer (was overwriting resources).
Remove legacy getParam() helper.

Coverage increased (+0.05%) to 90.784% when pulling 0675a5314457b000211dc49b24f76f98670041c4 on RickCarlino:6.4.0rc3 into af450fde3759885f8b58d5fcc7c299edbd4dd979 on FarmBot:staging.


added paradox prompt with ruby_info in rprompt

Added ruby-info to the existing paradox prompt on the right (RPrompt)

I do not want to duplicate themes in Prezto. Themes can and ought to be configured.

ok how would I configure paradox to have nvm and rvm prompt would love to know? Ill do it like that then if its possible.


B3 submission

Node ID:   2294b22d0478d9cd
FEEDBACKS:
Restart a node using local DB
It took 18 seconds (from 08:24:27 to 08:24:45)to catch-up and chain length = 95 (from 129399 to 129494)
Restart a node with --no-block-state-import
It took 1 second (from 08:32:01 to 08:32:02)to catch-up and chain lenght = 49 (from 129497 to 129546)

confirmed:B3

confirmed:B3


Local primary key on children

Is there a way to use a local pk in the child model instead of having it always point to the parent's pk?

That is not possible, as Django's multi-model inheritance uses that. This is not a polymorphic-specific issue.


Setting visibility="submission" results in the submission field being hidden

Describe the bug
If you attempt to sent any submission field to "submission" visibility, it will be entirely hidden in the submission form.
To Reproduce
Steps to reproduce the behavior:

Define any field as submission-only (<visibility>submission</visibility>) in your submission-forms.xml.  For example:

         <row>
              <field>
                  <dc-schema>dc</dc-schema>
                  <dc-element>title</dc-element>
                  <dc-qualifier>alternative</dc-qualifier>
                  <repeatable>true</repeatable>
                  <label>Other Titles</label>
                  <input-type>onebox</input-type>
                  <hint>If the item has any alternative titles, please enter them here.</hint>
                  <required></required>
                  <visibility>submission</visibility>
              </field>
          </row>

Submit a new Item which uses that form.  That field will not be visible in the submission form.

NOTE: If you submit the Item and it goes into workflow, that field will also not be visible in workflow.

Expected behavior
Fields which have <visibility>submission</visibility> should APPEAR in the submission form, but NOT APPEAR when the item is in workflow approval.
Related work
Discovered while testing #1828, but not directly related to that PR

Closing, this was fixed by https://github.com/DSpace/dspace-angular/pull/2297 in 7.6


Split Lin package

Refactor the Lin package into sub-libraries so that users can choose to use only the domain, the thread or the effect implementation. That way it is possible to test the domain and effect implementation in runs without running first the thread initialisation code.
Put the part of the interface that should not be used by external users into _internal modules. They can’t be really hidden (by using dune private_modules stanza for instance) without breaking the test suite.
This PR is really only about the couple of commits at the tip of that branch. They are currently based off an integration branch because it is meant to be merged when #112 will have been merged.

I've now taken a pass over this PR.
Overall I was very pleased to see how systematic it approaches the refactoring.
It made reading the diff commit-by-commit a pleasure! :smiley:
A few things I noticed - only related to naming really:

Why change ApiSpec to Spec? I think the former is more descriptive. InterfaceSpec may be more in line with established OCaml terminology though...
I'm not sure about the ExpandedSpec name as it is not very descriptive: such modules contain generators, printers, shrinkers, etc., so they are further from a 'specification'. I think of this old Lin as an internal test representation myself. Could Lin_internal.TestRepr and Lin_common.Make/Build_test_repr work? (other name suggestions welcome!)
Finally the old "Lin_api" and "Lin" test name prefixes should probably be updated in a separate commit of the PR

It also does not yet update the documentation, but I suggest we do this also in a separate PR. Since this one is modifying so many source files in our test suite, we would avoid a lot of conflicts by merging soon.

And rebased on main.

Thanks a bunch for this :pray:
I went over the commits again, found a small nit, committed a fix, and merged into main


Implement coset_order_to_circle_domain_order_index.

This change is

#728  👈
dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @alonh5 and the rest of your teammates on  Graphite

Codecov Report
Attention: Patch coverage is 0% with 5 lines in your changes missing coverage. Please review.

Project coverage is 89.91%. Comparing base (2501444) to head (3044bb5).
Report is 8 commits behind head on dev.

Files
Patch %
Lines

crates/prover/src/core/utils.rs
0.00%
5 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##              dev     #728      +/-   ##
==========================================
- Coverage   90.52%   89.91%   -0.62%
==========================================
  Files          76       82       +6
  Lines       10157    10714     +557
  Branches    10157    10714     +557
==========================================
+ Hits         9195     9633     +438
- Misses        879      994     +115
- Partials       83       87       +4

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


⚠ SolarOscp has degraded performance

In 617c1d0, SolarOscp ($SOLAROSCP_URL) experienced degraded performance:

HTTP code: 200
Response time: 452 ms

Resolved: SolarOscp performance has improved in 2ec00d8 after 24 minutes.


Consider a way to ensure that every ISI has a Validator

I'm not sure if this is even possible, but it's very desirable. Right now we can not be sure that existing validators covers all functionallity. We should try to figure out how we can automatically check this.
I like the way I did it in traits system for permission tokens in validators. When developer derives Token they should also implement Validate which requires validate_grant() and validate_revoke(). This way we can be sure, that every token has a validation for Grant and Revoke (which was a big problem before, because we often didn't check Revoke).
Maybe it will be not possible to do that in type or traits system. But there can be another way. Maybe with some tool which we can run in CI or something like that.

@Arjentix is this still relevant?


feat: add ffmpeg

Description

Motivation and Context

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Other changes (ci configuration, documentation or any other kind of changes)

Checklist:

[ ] I have created tests for my code changes, and the tests are passing.
[ ] I have executed the pre-commit hooks locally.
[ ] My change requires a change to the documentation (create a new issue if the documentation has not been updated).
[ ] I have updated the documentation accordingly.

:tada: This PR is included in version 1.1.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.4.3 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Will this work with wptouch?

Will this work good with wptouch?

Php7

The script has no impact on your PHP version. Basically, Rocket-Nginx serves files directly without calling PHP and WordPress at all.
I have not tested the script with WPTouch.

Due to inactivity, this issue will be closed.


Play Store closing itself

Play Store keeps closing itself after login in.
Open the app a few seconds after opening it close itself, maybe its a bug with the new GApps.
I installed WSA today, followed the tutorial, the other apps seams to work just fine.
Any idea how to fix it?

You installed suggested GApps? Today I install Pico variant, works fine!
https://github.com/WSA-Community/WSAGAScript#download-gapps-via-opengapps-project

Yes i installed the Pico version, not working fine for me, and i saw other #107 that have the same issue, So no its not working fine for everybody

I have found that when Play loads if you click off the homepage quickly, to say Apps, it stays open.

@Clinteastman what do u mean click off the homepage?

@Clinteastman what do u mean click off the homepage?

As soon as the Play Store opens, click on Apps from the main menu. It seems it's just the games tab that crashes.

It doesn't work, mainly because it almost always closes before showing anything (just the Play Store logo).
It may either be because the most recent OpenGApss version is for Android 11 wile the current WSA is Android 12 or because there was some issue during some app update.
I would like to know if there's a way to reinstall OpenGApps without having to repeat the whole installation ritual, to see if that fixes it.

It seems that the issue is with OpenGApps. When I installed MindTheGapps instead, this issue got fixed. At least for the first time.


commands

installed it, use tilde key to open the console, can drag it around and click- expand the window... but i cant type in it?
win10-lastest
i know the mod is working, cause it skips the intros...etc

Have you tried to use your mouse to click it?

We don't support cracked games.


[Bug]: Paligemma loading issues: RuntimeError: Input type (torch.cuda.FloatTensor) and weight type (torch.cuda.HalfTensor) should be the same

Your current environment
Collecting environment information...
PyTorch version: 2.3.0+cu121
Is debug build: False
CUDA used to build PyTorch: 12.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.4 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: Could not collect
CMake version: version 3.30.0
Libc version: glibc-2.35

Python version: 3.10.14 (main, May  6 2024, 19:42:50) [GCC 11.2.0] (64-bit runtime)
Python platform: Linux-6.5.0-1023-azure-x86_64-with-glibc2.35
Is CUDA available: True
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration:
GPU 0: NVIDIA A100 80GB PCIe
GPU 1: NVIDIA A100 80GB PCIe
GPU 2: NVIDIA A100 80GB PCIe
GPU 3: NVIDIA A100 80GB PCIe

Nvidia driver version: 535.183.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Architecture:                       x86_64
CPU op-mode(s):                     32-bit, 64-bit
Address sizes:                      48 bits physical, 48 bits virtual
Byte Order:                         Little Endian
CPU(s):                             96
On-line CPU(s) list:                0-95
Vendor ID:                          AuthenticAMD
Model name:                         AMD EPYC 7V13 64-Core Processor
CPU family:                         25
Model:                              1
Thread(s) per core:                 1
Core(s) per socket:                 48
Socket(s):                          2
Stepping:                           1
BogoMIPS:                           4890.88
Flags:                              fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw topoext perfctr_core invpcid_single vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves clzero xsaveerptr rdpru arat umip vaes vpclmulqdq rdpid fsrm
Hypervisor vendor:                  Microsoft
Virtualization type:                full
L1d cache:                          3 MiB (96 instances)
L1i cache:                          3 MiB (96 instances)
L2 cache:                           48 MiB (96 instances)
L3 cache:                           384 MiB (12 instances)
NUMA node(s):                       4
NUMA node0 CPU(s):                  0-23
NUMA node1 CPU(s):                  24-47
NUMA node2 CPU(s):                  48-71
NUMA node3 CPU(s):                  72-95
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit:        Not affected
Vulnerability L1tf:                 Not affected
Vulnerability Mds:                  Not affected
Vulnerability Meltdown:             Not affected
Vulnerability Mmio stale data:      Not affected
Vulnerability Retbleed:             Not affected
Vulnerability Spec rstack overflow: Vulnerable: Safe RET, no microcode
Vulnerability Spec store bypass:    Vulnerable
Vulnerability Spectre v1:           Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:           Mitigation; Retpolines; STIBP disabled; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
Vulnerability Srbds:                Not affected
Vulnerability Tsx async abort:      Not affected

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] nvidia-nccl-cu12==2.20.5
[pip3] torch==2.3.0
[pip3] torchvision==0.18.0
[pip3] transformers==4.42.4
[pip3] triton==2.3.0
[conda] numpy                     1.26.4                   pypi_0    pypi
[conda] nvidia-nccl-cu12          2.20.5                   pypi_0    pypi
[conda] torch                     2.3.0                    pypi_0    pypi
[conda] torchvision               0.18.0                   pypi_0    pypi
[conda] transformers              4.42.4                   pypi_0    pypi
[conda] triton                    2.3.0                    pypi_0    pypi
ROCM Version: Could not collect
Neuron SDK Version: N/A
vLLM Version: 0.5.1
vLLM Build Flags:
CUDA Archs: Not Set; ROCm: Disabled; Neuron: Disabled
GPU Topology:
GPU0	GPU1	GPU2	GPU3	NIC0	CPU Affinity	NUMA Affinity	GPU NUMA ID
GPU0	 X 	NV12	SYS	SYS	NODE	0-23	0		N/A
GPU1	NV12	 X 	SYS	SYS	SYS	24-47	1		N/A
GPU2	SYS	SYS	 X 	NV12	SYS	48-71	2		N/A
GPU3	SYS	SYS	NV12	 X 	SYS	72-95	3		N/A
NIC0	NODE	SYS	SYS	SYS	 X

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks

NIC Legend:

  NIC0: mlx5_0

🐛 Describe the bug
I tried running the following command and ran into this issue
CUDA_VISIBLE_DEVICES=2 python -m vllm.entrypoints.openai.api_server \
    --model google/paligemma-3b-mix-224 \
    --chat-template template_llava.jinja

[rank0]: Traceback (most recent call last):
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/runpy.py", line 196, in _run_module_as_main
[rank0]:     return _run_code(code, main_globals, None,
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/runpy.py", line 86, in _run_code
[rank0]:     exec(code, run_globals)
[rank0]:   File "/home/lmsys/vllm/vllm/entrypoints/openai/api_server.py", line 216, in <module>
[rank0]:     engine = AsyncLLMEngine.from_engine_args(
[rank0]:   File "/home/lmsys/vllm/vllm/engine/async_llm_engine.py", line 444, in from_engine_args
[rank0]:     engine = cls(
[rank0]:   File "/home/lmsys/vllm/vllm/engine/async_llm_engine.py", line 373, in __init__
[rank0]:     self.engine = self._init_engine(*args, **kwargs)
[rank0]:   File "/home/lmsys/vllm/vllm/engine/async_llm_engine.py", line 520, in _init_engine
[rank0]:     return engine_class(*args, **kwargs)
[rank0]:   File "/home/lmsys/vllm/vllm/engine/llm_engine.py", line 263, in __init__
[rank0]:     self._initialize_kv_caches()
[rank0]:   File "/home/lmsys/vllm/vllm/engine/llm_engine.py", line 362, in _initialize_kv_caches
[rank0]:     self.model_executor.determine_num_available_blocks())
[rank0]:   File "/home/lmsys/vllm/vllm/executor/gpu_executor.py", line 78, in determine_num_available_blocks
[rank0]:     return self.driver_worker.determine_num_available_blocks()
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
[rank0]:     return func(*args, **kwargs)
[rank0]:   File "/home/lmsys/vllm/vllm/worker/worker.py", line 179, in determine_num_available_blocks
[rank0]:     self.model_runner.profile_run()
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
[rank0]:     return func(*args, **kwargs)
[rank0]:   File "/home/lmsys/vllm/vllm/worker/model_runner.py", line 923, in profile_run
[rank0]:     self.execute_model(model_input, kv_caches, intermediate_tensors)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context                                                   [17/1835]
[rank0]:     return func(*args, **kwargs)
[rank0]:   File "/home/lmsys/vllm/vllm/worker/worker.py", line 179, in determine_num_available_blocks
[rank0]:     self.model_runner.profile_run()
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
[rank0]:     return func(*args, **kwargs)
[rank0]:   File "/home/lmsys/vllm/vllm/worker/model_runner.py", line 923, in profile_run
[rank0]:     self.execute_model(model_input, kv_caches, intermediate_tensors)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
[rank0]:     return func(*args, **kwargs)
[rank0]:   File "/home/lmsys/vllm/vllm/worker/model_runner.py", line 1341, in execute_model
[rank0]:     hidden_or_intermediate_states = model_executable(
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/home/lmsys/vllm/vllm/model_executor/models/paligemma.py", line 247, in forward
[rank0]:     vision_embeddings = self._process_image_input(parsed_image_input)                                                                                [0/1835]
[rank0]:   File "/home/lmsys/vllm/vllm/model_executor/models/paligemma.py", line 235, in _process_image_input
[rank0]:     image_features = self._process_image_pixels(image_input)
[rank0]:   File "/home/lmsys/vllm/vllm/model_executor/models/paligemma.py", line 229, in _process_image_pixels
[rank0]:     return self._image_pixels_to_features(self.vision_tower, pixel_values)
[rank0]:   File "/home/lmsys/vllm/vllm/model_executor/models/paligemma.py", line 217, in _image_pixels_to_features
[rank0]:     image_outputs = vision_tower(pixel_values, output_hidden_states=True)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/transformers/models/siglip/modeling_siglip.py", line 1013, in forward
[rank0]:     return self.vision_model(
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/transformers/models/siglip/modeling_siglip.py", line 912, in forward
[rank0]:     hidden_states = self.embeddings(pixel_values, interpolate_pos_encoding=interpolate_pos_encoding)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/transformers/models/siglip/modeling_siglip.py", line 304, in forward
[rank0]:     patch_embeds = self.patch_embedding(pixel_values)  # shape = [*, width, grid, grid]
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1532, in _wrapped_call_impl
[rank0]:     return self._call_impl(*args, **kwargs)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1541, in _call_impl
[rank0]:     return forward_call(*args, **kwargs)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/conv.py", line 460, in forward
[rank0]:     return self._conv_forward(input, self.weight, self.bias)
[rank0]:   File "/home/lmsys/miniconda3/envs/vllm-source/lib/python3.10/site-packages/torch/nn/modules/conv.py", line 456, in _conv_forward
[rank0]:     return F.conv2d(input, weight, bias, self.stride,
[rank0]: RuntimeError: Input type (torch.cuda.FloatTensor) and weight type (torch.cuda.HalfTensor) should be the same

Thanks for reporting this! I have submitted a fix.

@BabyChouSr could you check if the issue is still there if you specify --dtype float32 when launching the server?


fix(types): remove number type of provide

see https://github.com/vuejs/core/pull/2616#discussion_r947133221

Closing this based on @sxzz comment.
Numbers work as expected, they are converted to string internally
playground


added git and github important resources to contribute in soda project

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind new feature
/kind bug fix
/kind cleanup
/kind revert change
/kind design
/kind documentation
/kind enhancement

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Test Report Added?:

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind TESTED
/kind NOT-TESTED

Test Report:

Special notes for your reviewer:

@ichiragkumar Thanks for the PR but the changes cannot be added to this readme. I have added comments on how to proceed.
Closing this for now.


Use cases v4

Cookies is not a must, let us see if the static URL idea even works. If you know "no cookies" and/or static URL doesn't work, please say so. Otherwise we will talk about it in the next meeting anyway.

Should be okay now.


[Backport 1.7x] Update to thrust 1.9.8 on Windows (#18218)

The PR mitigates the build failure due to NVCC bug for building windows artifact.
Description
(Brief description on what this PR is about)
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

@leezu

@mxnet-bot run ci [unix-cpu]

@mxnet-bot run ci [unix-gpu]

@mxnet-bot run ci [unix-cpu]


Refactor package structure

Changes:

jobs -> core: this package outgrown its initial purpose and is
the package where we put important classes to manage the deployment
commands -> steps: Lots of the modules in the commands package
held no commands but where a registry of steps to use to deploy
the different parts.

The long term goal is to create import rules, for example:

core is forbidden to import from steps and commands

Can we rename sunbeam/versions.py to constants.py and move into core? We can move some constants like OPENSTACK_MODEL etc to this file? What do you think?

Can we move JujuStepHelper from sunbeam/steps/juju.py to sunbeam/core/juju.py since the class is used by classes other than sunbeam/steps/juju.py

1: I don't see it as a contradiction, JujuStepHelper is either used in the steps package, provider package or in the feature modules, which can draw from the steps package.
2: That's what I intended, but didn't want to get this in this PR, a lot of things already moved around, I can do it
3: I always felt this was the natural direction, (already happened in the maas provider). They can still live in their respective module at the moment.

1: I don't see it as a contradiction, JujuStepHelper is either used in the steps package, provider package or in the feature modules, which can draw from the steps package. 2: That's what I intended, but didn't want to get this in this PR, a lot of things already moved around, I can do it 3: I always felt this was the natural direction, (already happened in the maas provider). They can still live in their respective module at the moment.

For (1) JujuStepHelper predominantly gives functionality that is missing from JujuHelper (rather python-libjuju). And so to me it makes sense if JujuStepHelper is part of core.
Makes sense for your points (2), (3) - can be separate PRs later on.


@available enum issue on XCode 13

Hi @jorgenhenrichsen , I already fixed a bug that occured in XCode 13 (app store release version), uploaded on a fork of this repository. FYI, this is a screenshot that describes the error.

.
Thanks.

@hubertdaryanto could you pls open a pull request to get it merged with the base branch.
i am in need of this change from base.


Make first a required argument

The implementation is just changing the type of first from Int to Int!. This also refactors code around first and skip, the default for skip is now set in the schema.
There are also improvements to coercion, so we check that Int is an i32, and also accept Ints for ID and BigInt values.
I did some updates to docs/graphql-api.md, but that file is being simultaneously moved to the graph explorer docs, can I remove it so it's not duplicated?
Resolves #783. Required for #770.

Ah, and yes, feel free to delete the GraphQL API docs file. Adding docs for this on thegraph.com/docs/ has higher value I feel.

@Jannis great! I've deleted the docs file. Since you've already reviewed this, I'll merge this and follow up with the fix to coercion of input objects.


add listToRVector

Resolves #27
Adds the listToRVector (originally in the data service) method to PluginUtil.

As discussed in slack, we expect some more additions soon so not planning to cut a release based off of this merge alone.


Implement PHP RFC 0001: Restructure PHP

Per PHP RFC 0001 we are restructuring the PHP language family of buildpacks to make them more modular, up-to-date, and as a result, maintainable.
This issue serves as a meta-issue for tracking the implementation all of the restructure work amongst the implementation buildpacks and language family.
Issues

[ ] https://github.com/paketo-buildpacks/php/issues/472

[ ] https://github.com/paketo-buildpacks/php-dist/issues/324
[ ] https://github.com/paketo-buildpacks/php-composer/issues/260
[ ] https://github.com/paketo-buildpacks/php-composer/issues/259
[ ] https://github.com/paketo-buildpacks/php/issues/475

[ ] https://github.com/paketo-buildpacks/php-fpm/issues/3

Parallelizable:

[ ] https://github.com/paketo-buildpacks/php/issues/477
[ ] https://github.com/paketo-buildpacks/php/issues/478
[ ] https://github.com/paketo-buildpacks/php/issues/479

Parallelizable:

[ ] https://github.com/paketo-buildpacks/php/issues/481
[ ] https://github.com/paketo-buildpacks/php/issues/482

[ ] https://github.com/paketo-buildpacks/php/issues/483
[ ] https://github.com/paketo-buildpacks/paketo-website/issues/370

I'm working on https://github.com/paketo-buildpacks/php-fpm/issues/3, and I'm trying to get a handle on what functionality is required in the buildpack. Will the php-builtin-server buildpack created in https://github.com/paketo-buildpacks/php/issues/477 be responsible for generating the php.ini file the that the php-web buildpack currently generates? Or does the php-fpm buildpack need to generate that config file? Currently, the php-web buildpack writes the file into its layer during every build

@fg-j Hmm. This is a good question. Based off of my limited knowledge of PHP, I think the PHP FPM buildpack should only be responsible for configuring the php-fpm.conf file. I believe setting configuration in a PHP FPM config file overrides a php.ini file anyways. If a php.ini file is actually necessary to be generated, my instinct would be to have the php-builtin-server buildpack handle this, since the php-httpd and php-nginx counterparts generate their respective config files as well. This also  makes more sense to me since the php-fpm buildpack is an optional buildpack in this order grouping.
Happy for @paketo-buildpacks/php-maintainers to weigh in as well

My $0.02. I would suggest that we have the buildpack which installs PHP add a default php.ini file. This is traditionally how it's done. When you install PHP with apt or another package manager, that provides a default php.ini. It should also set PHPRC and PHP_INI_SCAN_DIR.
The individual buildpacks can then customize that by adding php.ini snippets to the PHP_INI_SCAN_DIR. Right now, that points to something in the application workspace. That is probably OK, we just have to regenerate those every time the buildpack runs. Alternatively, we could have a second buildpack-only location for that. You can add multiple folders to the scan dir.

It is possible to scan multiple directories by separating them with the platform-specific path separator (; on Windows, NetWare and RISC OS; : on all other platforms; the value PHP is using is available as the PATH_SEPARATOR constant).

In that case, I think https://github.com/paketo-buildpacks/php-dist/issues/324 needs to be updated to include generating a default configuration file (and possibly setting up the PHP_INI_DIR).

@fg-j
This addressed directly in the rfc.

php-dist:
Installs the php distribution, making it available on the $PATH

provides: php
requires: none

This distribution must include popular modules like memcached, mongodb,
mysqli, openssl, phpiredis, zlib etc; and a suitable php.ini.

@sophiewigmore Is this issue still being used to track work or are we done?

@ForestEckhardt as you can see, the documentation issue is still in review. That's the last remaining issue. I will close out this issue when that is available on the Paketo website.


ntr: sister chromatid separation during meiosis I, with normal disjunction PMID:21920317

I want to describe a phenotype where sister kinetochore split (bipolar attachment) , but segregation is normal....
fig 1D PMID:21920317

sister chromatid separation during meiosis I leading to equational segregation of sister chromatids during meiosis I
So these are the 2 phenotypes.
I'm not sure if they exist, but I don;t think so?

Hmm, I think I see a problem.
Sister chromatids can 'split' but become correctly separated is they have the correct SPB/kinetochore attachments, so its sort of 2 steps.
See Fig 3 for schematic
I guess we need to be clear about
i) sister chromatid 'separation', chromatids can split' due to merotelic attachment.
and
these can be correctly co-segregated
ii) equational segregation during mieosis I is observed

So currently
sister chromatid separation during meiosis I
equational sister chromatid segregation at meiosis I [exact]
could be
sister chromatid separation during meiosis I
--equational sister chromatid segregation at meiosis I
equational sister chromatid segregation at meiosis I
defined as  sister chromatid separation during meiosis I leading to equations segregation
of sister chromatids
(or similar)

new terms
sister chromatid separation during meiosis I followed by normal chromosome separation FYPO:0005633
sister chromatid separation during meiosis I followed by equational sister chromatid segregation FYPO:0005634
I included a couple of synonyms, and can add more if you think of any that would be useful.
updated some comments to refer to FYPO:0005634 instead of FYPO:0003604

changes so far in
edit file: c25adbc98d6aa70b5d5546fcda9e3fcf2d29ef84
release: 29a45a758b00fedb8ecd9abb0ec17625543a0302

I don't know what you added but I suggest
increased merotelic attachment in meiosis I (assuming this causes the splitting phenotype)

typo, term and def, 2nd separation->segregation
FYPO:0005633
Ontology	fission_yeast_phenotype
Term name
sister chromatid separation during meiosis I followed by normal chromosome separation
don't  stress ;)

No, "separation" is correct here, given GO's definitions. I'll correct the sibling.

I mean segregation. Its the complete segregation which happens correctly.

The overall segregation process isn't completely normal if it includes the sister chromatids separating during meiosis I.

OK, I always think of normal segregation as meaning that  everything is correctly segregated.
So here I am not only trying to capture that they eventually 'separate'  normally (I.e are no longer joined by cohesin or chiasmata or whatever) , but that everything is partitioned correctly (nothing is unequal, or . How can we capture that? Is normal disjuction more correct as that encompasses that all of the moving apart is correct?)

I would think if everything is partitioned correctly, separation must have been normal.
It occurs to me that this is one reason I bang on about distinguishing process phenotypes from  structure and other static phenotypes - in some cases you can reach a normal physical setup by either a normal process or one that's abnormal somewhere along the way, but not too badly to be put right.
"Disjunction" is just a word that's used in a slightly less precise way than the way GO uses "segregation" and "separation" in term names. It seems to me it's usually closer to "separation". (That said, the literature uses "chromosome segregation", "chromosome separation", and a zillion other words more loosely than GO does; that's one of the reasons we need ontologies.)

also, if you want that much detail, I could add a term for 'normal GO:0051758'
[Term]
id: GO:0051758
name: homologous chromosome movement towards spindle pole involved in homologous chromosome segregation
namespace: biological_process
def: "The directed movement of homologous chromosomes from the center of the spindle towards the spindle poles, mediated by the shortening of microtubules attached to the chromosomes, that contributes to meiosis I." [GOC:ai]
synonym: "homologous chromosome movement towards spindle pole during meiosis I" RELATED [GOC:dph, GOC:tb]
synonym: "meiosis I, homologous chromosome movement towards spindle pole" EXACT []
is_a: GO:0016344 ! meiotic chromosome movement towards spindle pole
relationship: part_of GO:0045143 ! homologous chromosome segregation

Closing because the originally requested terms are in. Open a new ticket if you want anything further.


Document how to use existing service principle

Added info on how to deal with existing service principals

@Teodelas,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot

I've included your contribution in PR #47 - thanks


How do I integrate it with bootstrap5?

I have an app running bootstrap 5.0.2 and wanted to use this multiselect.
As my app uses npm, I typed npm install bootstrap-select as docs suggested.
Then I added a select with selectpicker class into my HTML but it doesn't seem to work. Do I need to take some additional actions?

(I have jquery installed via link and it is before bootstrap-select. Console says There was an issue retrieving Bootstrap's version. Ensure Bootstrap is being loaded before bootstrap-select and there is no namespace collision. If loading Bootstrap asynchronously, the version may need to be manually specified via

It seems your issue is with loading bootstrap before bootstrap select. This is not a bootstrap-select issue, closing.