New pull request review workflow

Signed-off-by: Tibor Vass<EMAIL_ADDRESS>This proposal tries to bring better visibility in the pipeline of PRs, not only for maintainers but also for contributors. It would allow us to know how well we're doing design reviews, code reviews, docs reviews and better focus on improving bottlenecks.
It should also help not waste contributors' and maintainers' time by doing things in order (e.g. no need to ask to fix a coding style issue when the design was not approved).
Also, please keep in mind this is an experiment, and if it doesn't work we either fix it or revert it :)

Nit; should the title begin with "Proposal:"?
I like the suggestion of using more labels to keep track of progress/workflow. I'm not sure about the adding, then removing of labels. For example, once "docs" are reviewed, the 3-docs-review is removed; it may not be clear (at a glance) if docs was reviewed, or not yet reviewed.
Having a single 4-merge label could also be confusing here.
Maybe each discipline should have its own series of labels;
code-review -> code-merge
docs-review -> docs-merge
(And possibly other intermediate stages/states ("needs fix up", "ready for review"))
If both code-merge and docs-merge are present, a maintainer is allowed to merge. Basically, the LGTMs translated to labels.
Orthogonal, but for larger PRs I sometimes find it hard to track changes (maybe it's just me), because commits are squashed. For those PRs it could be helpful to only add commits during the review process and wait with squashing until review is completed.

We've tended to try to get the docs review done as early as possible - often, a non-coded proposal has Docs LGTM before the other maintainers have had time to comment - in the hope that we don't hold up the merge.
So I agree that having state based labels like docs-merge-ready and code-merge-ready would be useful - with those labels removable on major updates may also be useful.
having a single next process phase label as you're proposing would be really good for letting a user know what phase their PR is in - but they still may have trouble knowing who (and when) will action the next step.
over all LGTM

I gave a few opinions if that's ok, but overall :+1:

@thaJeztah Thanks for your input.
We already had an internal debate about whether to have a what-needs-to-be-done label, or a what-was-done label. We agreed that a what-needs-to-be-done label made more sense: for instance, docs maintainers would watch 3-docs-review labels instead of a 2-code-ok label.
What you suggested of having multiple state labels for each dimension (design, code, docs...) seems over complicating things.
Keep in mind that the goal of the proposal is not to solve and optimize every corner case; it's solely about bringing a little more structure while keeping the workflow somewhat flexible. It is totally open for improvements, however this is a small incremental step that I believe is needed.
Your comment about squashing makes sense. However I believe we should leave that for another PR. Think of it as yet another potential improvement on the workflow. However I don't want to make too many strong choices in this PR. Again, it's simply writing down how we tried to operate as maintainers.

:+1:

Just curious, what was the current pain point that cause this to be proposed?

@duglin updated main PR comment for you :)
@icecrime PTAL

I wonder if Other documentation-only PRs should get the 3-docs-review label applied makes sense for anything other than trivial changes.
Assuming that there is a substantial change to the documentation, then that PR will need a design review - to ensure that what has been written both reflects what the code does, and also, what the designer of that functionality intended.

@SvenDowideit I understand your concern. Again, the goal is to kick off the experiment and see how it goes and adjust with common sense. So if the triager believes it needs design review, it will put the design review label, if they think it's not needed they put the docs review label. If then maintainers disagree, they should probably discuss on IRC and upon agreement possibly change the label again.
It's all about common sense, it's not a rigid workflow.

mmm, perhaps we should add another step:

no-label
design review
code review
validation
doc review
merge

where all PR's must go through validation - which includes making sure that the documentation and the code match, and are a true representation of what is intended.
Its somewhat clear that I'm mostly doing something that the PR puts somewhere in the code review stage - where I'm trying to tease out enough information from the coder and code, and into the docs.

@SvenDowideit not sure I understand your last sentence, but yeah: what you call validation in the current proposal happens in the code review step. Is that a problem?

yes, for 2 reasons. The first is simple - you are skipping code-review when there's no code.
The second is more complicated - coders that have been involved in design and code review regularly forget to document something simple, because they're familiar with the feature (because of that technical knowledge).
Adding an explicit validation step reminds us to get another set of eyes to check the assumptions, or is done by QA.
most of the Doc reviews I've been doing are more about validation

@SvenDowideit you have valid points. I'm just wondering whether it's not overcomplicating it. I agree that we should check for consistency between code and docs, but I still feel it should be done during code review. If it doesn't work well and there are multiple cases where maintainers overlooked consistency with docs, then I'd say yeah maybe we need a specific step. That's my personal opinion.
I'd like other maintainers' opinion on validation. /cc @icecrime @crosbymichael @jfrazelle
Generally speaking, I'd like to stress that I'd love to have a general agreement and start experimenting and possibly iterate on it, otherwise we could be stuck forever in debates.

Is there a way that Github's support for the Task Lists in markdown could be of value, possibly by maintainers editing the initial issue description, to track a history of whats been done, or has to be, and then labels are become a filter on what stage its in now?  Potentially simpler than a label-based state machine, and quite flexible
Something like:

[x] proposal needs looked at
[x] docs reviewed by @SvenDowideit
[ ] @wyaeld to code

@wyaeld One thing we want (and need) is the ability to filter PR on their state. As a code maintainer, I need to know what needs review and start helping, or what's ready for merge and give it the last push. I don't want to actually have to read the PR to see where it's at (especially long running ones with tons of comments and mixed reviews of design/code/docs where in the end it's getting harder and harder to determiner what's the next step).

sure, I didn't mean as a replacement for labels tracking and filtering on the current stage, just an a supplement since people had mentioned that tracking what has been done wasn't trivial

@icecrime @wyaeld
I would be cool to have a bot modify the description of peoples PRs to add a checklist of all the processes and order that has to go through.

Coming back to this PR, which I think is of great importance. Two things I'd like to add:

The "right moment" for docs review has been discussed, but not perfectly agreed on it seems. I think this comment and my reply properly sum up the debate. I still stand very strongly on my position fwiw.
About final validation and overall consistency: the "4-merge" step doesn't have to be just about pressing the button: it's the opportunity for a maintainer to give it a last look and even bring back to an earlier step if necessary.

In addition to the proposed workflow/labels, and I'm not sure that should be part of this proposal or a separate one (so please correct me if this is the wrong place); please define tags for the "outcome" of the review process and the issue in general. Some tags like design rejected, wont-fix, cannot reproduce, on hold, input needed, fixed etc.
I've seen many occasions that people comment on closed issues, asking "why was this closed", "is this issue resolved", etc. Having labels to indicate the status of closed issues can (hopefully) prevent such comments, which may save the maintainers some work in the long run.
Obviously adding those labels would require some extra work, so if it's possible to add those labels automatically (or an easy way to add them) can be important there.

Agree with @crosbymichael and @icecrime.
Will rebase into the new MAINTAINERS file and add some clarifications.

@thaJeztah why not, the only downside is "label pollution". I still would like to stick to the goal of having this as simple as possible. If we feel it's necessary to add more labels, we can debate it later.
I still believe that in your example, if someone sees that a PR is closed at "design-review" it's different than a PR that's closed at "code-review". Also, getting to the bottom of the page shouldn't be too difficult either.
However if we deem important to have stats on the reason for closing PRs, that's another debate I'll be happy to have another time.

@tiborvass agreed, I think those labels should be discussed in a follow-up proposal; they won't assist the general workflow directly. I do think they could add value and statistics is something I didn't think of, but an interesting thought. I'll keep this in mind, may create a separate proposal for the other labels.

LGTM!

ping @fredlf

Made a couple of comments, but otherwise, LGTM.

@fredlf updated!

LGTM

LGTM

much conversation, that i'm not entirely prepared to read ATM.
Overall LGTM. I assumed though that the workflow that this will be a part of, will be a layered/automated approach?

@vbatts It will be as automated as it can possibly be. For that to happen we need to define what "code approval" means, preferably in git and not with github comments. Also the number of approvals from different subsystems, etc. all that has to be defined and scriptable, and then it's the holy grail.
In the beginning, we'll have to manually remove and add labels.

+1 for use of GitHub task lists. It's great to go through inline comments and make sure they're fixed correctly. However then this brings another layer of complication in addition to the labels. We can have list of stages as GitHub task lists but then they wouldn't give any querying benefits. I think proposal seems fine atm.
Overall LGTM.

LGTM

Idea is okay for me. LGTM

LGTM

Ping @vieux @vishh @dmp42 @dmcgowan @jlhawn @stevvooe @shin- @samalba

LGTM

LGTM

LGTMETA

Thanks folks!


NullReferenceException: Object reference not set to an instance of an object Avatar

NullReferenceException: Object reference not set to an instance of an object
OvrAvatarSkinnedMeshPBSV2RenderComponent.InitializeSingleComponentMaterial (IntPtr renderPart, Int32 lodIndex) (at Assets/Oculus/Avatar/Scripts/OvrAvatarSkinnedMeshRenderPBSV2Component.cs:91)
OvrAvatarSkinnedMeshPBSV2RenderComponent.UpdateSkinnedMeshRender (.OvrAvatarComponent component, .OvrAvatar avatar, IntPtr renderPart) (at Assets/Oculus/Avatar/Scripts/OvrAvatarSkinnedMeshRenderPBSV2Component.cs:77)
OvrAvatarComponent.UpdateAvatar (ovrAvatarComponent component, .OvrAvatar avatar) (at Assets/Oculus/Avatar/Scripts/OvrAvatarComponent.cs:56)
OvrAvatar.UpdateAvatarComponent (ovrAvatarComponent component) (at Assets/Oculus/Avatar/Scripts/OvrAvatar.cs:285)
OvrAvatar.UpdateSDKAvatarUnityState () (at Assets/Oculus/Avatar/Scripts/OvrAvatar.cs:418)
OvrAvatar.Update () (at Assets/Oculus/Avatar/Scripts/OvrAvatar.cs:624)
Yes I Draged and droped [VRTK_SDKManager]  from Prefabs  into scene
Avatar Shaders missing?

OK dont even bother
[VRTK_SDKManager] has to be taken from prefabs
LocalAvatar also has to be replaced with its Prefab version
From some Reason references in Scenes are missing

This has been fixed in the latest github master branch


Public Collective activity timeline

The idea was initially developed in https://github.com/opencollective/opencollective/issues/5195

I'm thinking perhaps a better way to consider this "public activity log" project would be creating different options for viewing a Collective's page: a 'Section' view or 'Timeline' view.
Use cases:

I'm a host admin and I need to see when a Collective that we used to host left my host
I was an admin of a Collective and got removed - I want to see who kicked me out and when
I'm a journalist writing an article about a Collective and I want to see when it started and some of its milestones
I'm a volunteer who gets reimbursed from a Collective, and I need to see when the expense policy changed and who changed it

This one will be easier to implement now that we have the activity log. It could be a frontend-only issue.


Wake on Notification on Android

This might not be an issue...
I don't know where to ask this.
So I made my android push notification worked, however I want to wake my android devise screen on when I receive the push notification. I get sound and vibrate, I just need to turn on the screen.
I am a ios user, so it might not understand how android handles push notifications...
Please help me with this :D
Thanks

I am using 14.0.0 - mine is not waking. Do I need to include some permission?

hello, I've checked that wake_screen is already in the source code, but how to use it? I already add wake_screen inside the payload, but still no luck.

@NinoMartino i also couldn't figure it out.


Word Wrap for Labels

Is there a way to have the labels automatically word wrap when the funnel is either large (wider) or smaller (narrower) so that the labels stay within the funnel?

This is not supported, yet. It's a bit non-trivia because SVG text elements require very specific calculations and word-wrapping is not natively supported. The library would have to manually force newlines if the width would necessitate it.
As shown in the examples, you can override label.format to inject newline characters to force manual wrapping between the label and value yourself. You can also add newlines to the individual labels if necessary:
const data = [
    { label: 'Inquiries', value: 5000 },
    { label: 'Applicants', value: 2500 },
    { label: 'Admits', value: 500 },
    { label: 'My Long\nDeposits Label', value: 200 },
];
const options = {
    label: {
        format: '{l}\n{f}',
    },
};

const chart = new D3Funnel('#funnel');
chart.draw(data, options);

As far as the D3Funnel library handling this, it is not on the immediate horizon.


Pull-to-Refresh

Good, as it could do to add to the tableview a pull to refresh or where in the same should write the code to do that ?. I'm programming in swift 3

Hi, Pull to refresh and Tableview are not related to the library. You can add this function in your sub UIViewControllers.
Use the built-in UIRefreshControl to implement this function is very easy. Or you can find some brilliant 3-party libraries at Github.


updating docs to drop using --wipe flag

Fixes #439

Question: How to preview mdx files locally

I think there is a difference in how you use Restate locally for development/learning, vs production usage.
I think when developing locally, it's perfectly fine to use this a lot.
When developing locally, I still use it in quite some circumstances:

Running an example, then another example and wanting to start from a clean slate
Having many in flight invocations, delayed invocations and timers that I want to stop immediately to start over
It's still the fastest way to kill all invocations and state, if I have messed things up.

But yes, maybe doing rm -rf is also fine.

@gvdongen The argument --wipe is still available and you can use it. It's just hidden for normal users, and is then removed from documentations. You still can perfectly do restate-server --wipe all .


Add: Rede Premium [BR]

Channel Name
Rede Premium
Alternative Names (optional)
No response
Network (optional)
No response
Owners (optional)
No response
Country
BR
Subdivision (optional)
BR-SP
City (optional)
Osasco
Broadcast Area
s/BR-SP
Languages
por
Categories (optional)
Entertainment
NSFW
FALSE
Launched (optional)
No response
Closed (optional)
No response
Replaced By (optional)
No response
Website (optional)
https://redepremiumtv.com.br/
Logo
https://redepremiumtv.com.br/wp-content/uploads/2018/10/logo-site1-2.png
Notes
https://5c483b9d1019c.streamlock.net/8066/8066/playlist.m3u8

Thank you for the stream: it will be included in the next release.


Service worker registration is inline

It would be a lot better if we could have that registration src as a file so that we could remove 'unsafe-inline' from the CSP to protect from XSS, etc.

Another possibility would be creating a build time nonce to allow the inline service worker.


DragLayer + tbody: fires beingDrag then endDrag immediately

I'm attempting to drag-and-drop  elements but hitting a blocker.
I attempt to grab the dragSource from where the dragLayer would appear but immediately dragEnd fires immediately after dragStart.
Any idea what I'm doing wrong?  Using the regular screenshot from the HTML5 backend works fine.
I've built a sample application to demonstrate the issue here

Fixed!
I think it's because the dragPreview layer always needs to be 'fixed' position off screen, then moved only with transform?  Pushed my working branch.

@butchmarshall I am having this same issue and cannot seem to fix it (I am using connect.dragPreview() - not a custom DragLayer).
I have a few groups of items, much like your tables (items of divs within divs).  I can drag and drop items in the first few groups at the top of the page, however, items in groups lower on the page cannot be dragged.  endDrag fires immediately after beginDrag.
I tried removing the drag preview but it was still broke.
I tried looking at your code but there are a lot of changes in the commit that fixed it.  I was hoping that you could elaborate on underlying issue/solution for me.
Thanks in advance!

It turns out I can fix the issue if I change the type ('Item') of the DropTarget on the Category.   However, this is not a solution as it means that I cannot drop on the category.

Huh, I'll have to get back to you on exactly what I did here - it was awhile ago!
I believe the only solution I could come up with though was using a custom drag layer.


Support for DynamoDB Local

Is there any support planned for a local DynamoDB testing environment? e.g. when the endpoint property is given as configuration parameter.
dino.connect({
    accessKeyId: config.aws.AWS_ACCESS_KEY_ID,
    secretAccessKey: config.aws.AWS_SECRET_ACCESS_KEY,
    region: config.aws.AWS_REGION,
    endpoint: config.dynamoDB.endpointUrl //http:localhost:8000
});

So the current variant in github supports this but not the variant in npm. Need to poke @christophercliff to publish to npm again.

So the current variant in github supports this but not the variant in npm. Need to poke @christophercliff to publish to npm again.


How Much data can azure datawarehouse hold?

Is there any limit on how much can we store inside the azure datawarehouse?

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

ID: 99dbdf95-1c64-48c5-cc47-8d06d0975151
Version Independent ID: 0763ac70-8c4b-a8bc-c72c-e87bc45f46ba
Content: Capacity limits - Azure SQL Data Warehouse
Content Source: articles/sql-data-warehouse/sql-data-warehouse-service-capacity-limits.md
Service: sql-data-warehouse
Sub-service: design
GitHub Login: @happynicolle
Microsoft Alias: nicw

@Anmolgan81 The Database Objects (Link) section details all the applicable limits based upon Gen1 and Gen2 deployments but I think you are specifically looking for storage limits:

Gen1: 240 TB compressed on disk. This space is independent of tempdb or log space, and therefore this space is dedicated to permanent tables. Clustered columnstore compression is estimated at 5X. This compression allows the database to grow to approximately 1 PB when all tables are clustered columnstore (the default table type).

Gen2: 240TB for rowstore and unlimited storage for columnstore tables

Please let us know if you have any additional questions.

We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


Supported raw protobuf typed value using ydb.ParamsBuilder()

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Other information

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

Project coverage is 43.49%. Comparing base (12ee877) to head (e0bbf8a).

Files with missing lines
Patch %
Lines

internal/value/value.go
0.00%
17 Missing :warning:

internal/types/types.go
0.00%
14 Missing :warning:

internal/params/parameters.go
0.00%
5 Missing :warning:

internal/params/builder.go
33.33%
2 Missing :warning:

:exclamation:  There is a different number of reports uploaded between BASE (12ee877) and HEAD (e0bbf8a). Click for more details.
HEAD has 131 uploads less than BASE

Flag
BASE (12ee877)
HEAD (e0bbf8a)

unit
18
1

go-1.21.x
12
1

ubuntu
26
0

go-1.22.x
12
0

macOS
6
1

go-1.23.x
14
0

integration
18
0

ydb-23.3
6
0

windows
6
0

ydb-24.1
6
0

ydb-24.2
6
0

ydb-nightly
2
0

experiment
2
0

Additional details and impacted files
@@             Coverage Diff             @@
##           master    #1576       +/-   ##
===========================================
- Coverage   71.03%   43.49%   -27.55%
===========================================
  Files         363      296       -67
  Lines       37728    31938     -5790
===========================================
- Hits        26800    13890    -12910
- Misses       9833    17571     +7738
+ Partials     1095      477      -618

Flag
Coverage Δ

experiment
?

go-1.21.x
43.49% <2.56%> (-26.89%)
:arrow_down:

go-1.22.x
?

go-1.23.x
?

integration
?

macOS
43.49% <2.56%> (+2.45%)
:arrow_up:

ubuntu
?

unit
43.49% <2.56%> (+2.44%)
:arrow_up:

windows
?

ydb-23.3
?

ydb-24.1
?

ydb-24.2
?

ydb-nightly
?

Flags with carried forward coverage won't be shown. Click here to find out more.

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


[keymgr] Add shadow registers to keymgr

The first 3 commits will be rebased away.

Thanks. It is the good example of how to implement shadow registers and connect alerts indeed. I will follow this example in PR #7439

gah! CI failed...maybe don't follow this example... hehe


Listview DataSource error

Hi I am using react-native version 0.21.0
var  ds = new ListView.DataSource({         rowHasChanged: (row1, row2) => row1 !== row2,       });
is showing the below error (Android). I am developing the app in Mac.

@facebook-github-bot stack-overflow

Please let me know, if this bug is because of me or react-native.
This is really urgent.


System Error

Any idea why this might be happening.

u need to download http://www.microsoft.com/download/en/details.aspx?id=26999

Yeah already did that. no worries, thanks anyway.


Enablement of AIFC development object for AIF content in abapgit

AIF developments, like AIF interfaces can be transported with the AIF Content Delivery Tool. An own repository table and transport object "R3TR AIFC" was introduced for transporting AIF content. A developer can compress C-Table entries from dev system into a blob-like repository table with TADIR entry, this will be transported and extracted in the target system.
In the future there will be more and more scenarios where it is necessary to use AIF developments in the onPremise and the cloud world.
For that reason, we are looking for a possibility to transport an AIF interface developed (by customer) in an onPremise landscape into S4 cloud landscape.  The usage of ABAP Git will allow scenarios like this.
I did a first implementation for the abapGit version in NW Infinity Development System to get a first feeling about what is needed to enable AIFC development object in abapGit.
The new AIFC serializer zcl_abapgit_object_aifc is stored in fork D047539/abapGit: Git client for ABAP (github.com) and branch aifc (see abapGit/src/objects at aifc · D047539/abapGit (github.com) ).
I am looking forward to your feedback and the discussions. Can you also tell me the next steps in order to trigger the approval process?

cool 👍
Next step will be to open a pull request
Quickly looking through the code:

Run the pretty printer for the class definition
use TYPE c LENGTH 6, instead of TYPE char6,, we would like to reduce dependencies into DDIC

thanks a lot for your feedback.
I triggered the pull request #5197.
What's next? What are the next steps?

can you help with some hints on how to test this, creating the AICF object? The link in the first comment to help.sap.com seems to not work?

please try this link: https://help.sap.com/viewer/4db1676c3f114f119b500bd80ccd944d/202110.000/en-US/13f753cfe3df4437b3b1434d1170a6ae.html

merged

Follow-up in #5250. Closing


replace /usr with %{_prefix}

Example:
python scons/scons.py PREFIX=/usr ==> python scons/scons.py PREFIX=%{_prefix}

If I could point your eyes to file rpmsection.py There is function replace_known_dirs which needs tweaking. Could you do it?

OK, will look at it

closing as it is merged


Can't deploy to a recent CF

I tried deploying to CF v251 in order to be able to test some copy changes in usability testing.
I hit the problems described in cloudfoundry/ruby-buildpack#75 because this app tries to use ruby 2.3.0, which is not supported by recent ruby buildpacks.
As pointed out in that issue, this happens because final_app/Gemfile contains this line:
ruby '2.3.0'
I don't really understand how to fix this myself.

Hi @bleach! Good point. We should document what users should do in this case. I  know for our (docs) apps, we do one of two things: 1.) mod final_app/Gemfile to use 2.3.3 OR 2.) push using a specific buildpack that does support 2.3.0. But we should probably find out the "official" stance and document it.

Ok. I'm using 1) now. 2) is not an option for me, as custom buildpacks are not enabled on our CF

Thanks for replying!

Hey @bleach! Just wanted to let you know that I pushed an addition to the Ruby buildpack documentation: https://github.com/cloudfoundry/docs-buildpacks/commit/7e45db12325cc6058a4fbd747f99cbd6d442c82a.

@ljarzynski thanks for looking at this.
I think the drawback to suggesting that users select old buildpack versions in the documentation is that it encourages users to install unsupported ruby versions. This will likely leave them missing security patches. It's a short term measure, that at best delays the need to make the app use a newer ruby. I'd encourage you to revert the change you made.
What I was hoping for was that this application could be brought up to date to run on the latest ruby buildpack. I had a go at this previously, but ran into the problems described, which the ruby buildpack team pointed out were due to final_app/Gemfile still specifying the old version. Ideally someone who understands more about the internals of this app would be able to suggest how it could be made to work on the latest ruby buildpack version.

@bleach Thank you for the feedback. Given that, I agree it would be best to remove the suggestion to use an older buildpack. Do you think we should leave the the second bit in about updating the Gemfile?

@bleach Just wanted to bump this to make sure you saw @ljarzynski's question.

@ljarzynski @bentarnoff apologies, I hadn't seen the question.
The ruby buildpack documentation seems to already have clear guidance on specifying ruby versions: http://docs.cloudfoundry.org/buildpacks/ruby/index.html#supported_versions
IMO the README for this repo, docs-book-cloudfoundry could be updated to state what a user is supposed to do to deploy to a recent CF. Or (my preference) the build process could be changed so it works out of the box (I'm not sure how to do this though).
But my original problem is solved, albeit in a non-ideal way.


Information about use / examples in README

First I want to say thanks for making JsBarcode available to use in more than the standard way :smile:
But the information in the README is a bit sparse and some information about how to use the library should be added.

Wow, the actual creator :D
I hope this module might be useful for someone, I created it for a personal project and I though I might as well share it.
I definitely agree, I did just update it and should be better now.
There are still quite some bugs that need fixing, this project is still in alpha right now ;)

Nice :smile:
Take your time with the project, but if you consider it stable in the future let me know. I'm thinking of linking this project and react-barcode from the JsBarcode Readme for people that need it and using angular / react.


Fix changeset helper to use casted embedded struct

Fixes #162

Pull Request Test Coverage Report for Build 1113

15 of 15 (100.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 100.0%

Totals

Change from base Build 1109:
0.0%

Covered Lines:
489

Relevant Lines:
489

💛  - Coveralls


Game unusable when using borderless fullscreen on laptop dGPU

Hi!
I have been using this mod without an issue for several days now using my laptop's integrated GPU. I wanted to test out the performance difference between the iGPU and dGPU but can't get my game to work properly in borderless fullscreen when using the dGPU. Normal fullscreen and windowed mode work fine on the dGPU.
Here is a video of the issue.
As an aside, this is the weirdest bug I've come across, I think..
Thanks,
~Luke

Oh. My. God. Windows is the gift that just keeps on giving, isn't it? Well, technically, there's some finicky stuff happening on the AMD drivers' side, but still, this isn't a problem on other platforms.
After quickly skimming through the internet, I found issues that AMD users had on Windows with some fullscreen apps, which sound similar to our case:

AMD drivers were plagued with a bug throughout 2022 and much of 2023 which makes the screen freeze [...] when you make a game in the background fullscreen. [...] It was resolved months and many drivers later, but the 24.3.1 update brought it back and it's even worse now.

So, I guess, try downgrading or upgrading your drivers?

I've reverted the default fullscreen mode used by CWB on Windows back to windows:windowed, which should help circumvent your issue.


Unable to find a specification for Tabby

hi
it seems like that this library cannot be found via CocoaPods
i add pod 'Tabby' inside my podfile, but i cannot find this awesome pod

pod 'Tabby', git: 'https://github.com/hyperoslo/Tabby'

but it's not working because of swift 4.2

Hi @comonitos,
thanks for your response
but I've fixed it by just use another lib
best,
Jamfly

Hi, whats name of another lib you used?

@fukemy, sorry it has been years, I've already switch my focus from iOS development to NLP. Unfortunately, I forget the actual pod name. Sorry I could not help.


Waves effect triggered when user touches and drags the element on mobile screen to scroll the page

Description
Waves effect triggered when user drags the element on mobile screen to scroll the page. It's quite common when applying the wave effect to a card component, which may cover bigger area of mobile screen.
Repro Steps
Open http://materializecss.com/cards.html on mobile device, nav to "Card Reveal" section and drag it to scroll.

I believe this is standard material behavior. You can see it happen in the
Android system notifications panel
On Sat, Dec 24, 2016 at 4:14 AM Favo Yang<EMAIL_ADDRESS>wrote:

Description
Waves effect triggered when user drags the element on mobile screen to
scroll the page. It's quite common when applying the wave effect to a card
component, which may cover bigger area of mobile screen.
Repro Steps
Open http://materializecss.com/cards.html on mobile device, nav to "Card
Reveal" section and drag it to scroll.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/Dogfalo/materialize/issues/4027, or mute the thread
https://github.com/notifications/unsubscribe-auth/ACpax64p0tSVN3yC7LphpjPdM1brXzSzks5rLOJkgaJpZM4LVMUS
.

New to material design, please correct me if I'm wrong.
On mobile screen when an user starts scrolling a page by dragging any place on the screen, the purpose is clearly to navigate more page content. But if the user presses on a button or a card, the wave effect been triggered, it looks like a mistake by the user.  And even worse, the element that is moving out of screen try to get your attention. It's not a bit deal for small button, you barely noticed the wave effect, but quite notable for bigger element on the screen.
See the demo gif.

What is your preferred behavior? There isn't a way to know if someone is going to just tap or tap then drag to scroll.

Move the wave effect to touchend event handler, then you can detect it's a tap or a drag (by recording the touch position in touchstart event first).

The wave that appears on tap is there to let the user know that the object is clickable. Having the effect on touchend would prevent that.

How about setup a a very short timer to check the tap-vs-drag logic? Same idea to solve other tap-vs-drag issue on mobile, like when you tap on a tableview cell and start dragging, the tableview cell won't get highlighted.

I too have an issue with the way the waves effect functions while using is scrolling. I have checked many apps on my android device and I cannot find a single app that has this same type of effect. Touchend seems like a good solution but that defeats the purpose of letting the user know that an element is clickable if they tap and hold an element. Perhaps timer is the way to go but who wants to dirty up the dom with that... not me. I will see if I can find a remedy that doesn't sacrifice user experience.

Actually, this is the behavior that I can find in all Google apps (Inbox, Play Store, Play Music, etc). It's slightly different though. When you tap an area you do see the wave effect, BUT as soon as you start scrolling wave effect fades away (disappears).

@siburny That should be the solution, Google Play also uses it.

I agree to the last solution. It would be nice if the waves stops when scrolling/dragging starts.
I've got the issue on navbar with collection.

Any news on that? Did you guys using some another approach as workaround?

Interested! Any news/workarounds?

There is a small delay implemented in the latest version of Waves.js: https://github.com/fians/Waves/blob/master/src/js/waves.js#L108 (200ms)

This is a PR to upgrade Waves.js to the latest version. But can extract just the fixes for this issue if needed

@siburny I tried adding the delay: 200 to materialize.js but there was no change in the scrolling behavior for the waves effect, so I'm definitely interested in the fix for this if you can extract it for Materialize 1.0.0!!! TIA

If anyone is still interested I implemented a workaround for this on my own fork here.
When it detects that the user begins dragging it starts fading out the wave immediately.


chore(package): update grunt-cli to version 1.2.0

beating https://greenkeeper.io/ to the pr

local rebase and
rm -rf node_modules
npm install
npm run test
grunt saucelabs


1.5.3 download contains 1.5.2 mousetrap.js

It seems that the source code zip download for the 1.5.3 release contains the mousetrap.js for 1.5.2, although the mousetrap.min.js is 1.5.3 as expected.

I'm pretty sure it is actually 1.5.3, but I just forgot to increase the version number in the file

Yup ab4327c82b1b2e38b1d8ac5576f32a49e4441ea3

I get this (very minor diff)
$ diff ~/Downloads/mousetrap-1.5.2/mousetrap.js ~/Downloads/mousetrap-1.5.3/mousetrap.js
413c413
<         if (element === document) {
---
>         if (element === null || element === document) {

Yes.  That is all changed in version 1.5.3. See #275
I just forgot to increase the version number in mousetrap.js until after I tagged the release.  The code is the 1.5.3 code.


Move UpdateUser methods into after_update callbacks on User

Questions

Does this approach broadly make sense?
I'm fairly confident that moving the creation of EventLog records makes sense to do in callbacks on User, but I'm slightly less sure about sending email notifications. I think it still makes sense, but I'll probably need to be very careful that the logic is implemented correctly so that e.g. we don't end up sending out emails multiple times.
I think the user's permissions are going to be slightly more awkward to deal with, because everything else relates to attributes directly on the User record. However, I think we can either use callbacks on the UserApplicationPermission join model or implement some custom ActiveModel::Dirty-esque methods to detect changes to a user's permissions. The former would be conceptually simpler, but it would mean that we'd lose the ability to group permission changes together, so we'd end up e.g. creating multiple EventLog records (one for each user permission that's changed) and sending multiple SSO Push Updates out to each app. The latter might not be a problem though.

I'm going to try to get the bulk of this merged in #2623. Closing this PR for now.


API to select the segment to display

Great project! So thanks for open sourcing it.
Quick question: I looked at the API but I can't seem to find a way for selecting the segment I would like to display.
Imagine the case where depending on the action the user did in a previous ViewController, when the SJSegmentViewController is shown, I need to show the 2nd or 3rd segment when it appears on screen. Right now the default behavior is always to show the first segment, but I would like to be able to specify something like:
self.segmentedViewController.selectedSegmentIndex = 2
and when it goes on screen, it is automatically showing the proper segment.
thanks

@yodasl, we have added a function, func setSelectedSegmentAt(_ index: Int, animated: Bool) to select a segment in latest version 1.3.3.
segmentControl.setSelectedSegmentAt(index, animated: true)
Could you please use the latest version and check?

Thanks... I was still on 1.2.2 and upgrading to 1.3.3 I see now the new API... You may want to consider updating the README so when adding the reference for the pod for SJSegmentedScrollView to use 1.3.3


be able to provide own contexts

For example, this could be useful when you want the context to be something other than a window, e.g. a container div.

Did #13 really close this? It seems like window is still hard-coded here.
Happy to PR this if you agree.
(Thanks for this awesome addon!)

Good catch, you're right the hardcoded window should be removed


Remove python38 typing

Also, maybe we should consider using something like mypy to check if the types are actually correct


perf(registry): improve MagicCard performance with useCallback and extend interface for enhanced flexibility

Summary
Improve the performance of the MagicCard component by optimizing mouse event handling and gradient effect updates.
Changes

Optimized Mouse Event Handling: Added useCallback to memoize handleMouseMove and handleMouseLeave functions, reducing unnecessary re-renders.
Improved Gradient Management: Added handleMouseLeave to reset the gradient effect when the mouse leaves the component.

Benefits

Smoother Performance: Reduced re-renders and optimized gradient updates.
Resource Efficiency: Improved handling of mouse events and gradient rendering.

Example Usage
import { MagicCard } from './components/MagicCard';

export default function Example() {
  return (
    <MagicCard
      gradientSize={200}
      gradientColor="#ff5722"
      gradientOpacity={0.8}
      className="example-card"
    >

Hello, MagicCard!

    </MagicCard>
  );
}

Related Issue
#194

very well done thanks for adding this! LGTM


[Astar] [Paras NFT] [USAGII] Add USAGII NFT collection from Paras

If you want to integrate an asset (fungible token/ NFT), you would need to provide

Name of the asset: USAGII
Origin blockchain of the asset: Astar
Is it available on other blockchains? No
Metadata of the asset (symbol, decimals, smart contract address, on-chain metadata like assetId,...)
Contract address:  WvyVtR9Ktvxa9fRRFJPXvEgYTU5K5Lf491xzFhMQL3haDN6
Type: PSP34
Logo of the token
Is your asset transferable? Yes

Version test: https://file.cdmteck.com/s/4oimk9zDJ8R5Aai/download?path=%2F&files=./master-pr-1520-build-1.0.8-2023-06-12T09-05-50UTC.zip
- Check with address: YDTpoNMbS9fCUqXMnwDcFb8NmfMqBxx2ugwSAwYHeGH9ZGY
Validation passed for cases:

Show NFT
Send NFT (approve step)


Initial controller code.

This stands up a controller using ko. The controller does nothing
right now, other than register watchers on TaskRuns and log
reconciliation events.

/test pull-tekton-chains-build-tests

@dlorenc Is this mostly leveraged from tektoncd/pipeline? Would it be possible to split out the commit into generated and non-generated code?

@dlorenc Is this mostly leveraged from tektoncd/pipeline? Would it be possible to split out the commit into generated and non-generated code?

So everything outside of vendor/ is non-generated. I think we can add a github config to hide these by default. I'll look into it.

So everything outside of vendor/ is non-generated. I think we can add a github config to hide these by default. I'll look into it.

OK, I added the .gitattributes file to mark those as generated. Github should hide those now.

Thanks @dlorenc ! I was thinking for making it easier to review as GitHub won't show the entire diff, only the first 3000 changed files. But it looks like there's only 3 files (GitHub was smart enough to conveniently include them at the top) and the rest is generated.
/approve
/lgtm


[Enhancement] Upgrade hudi dependency version to 0.12.1

What type of PR is this：

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

upgrade hudi dependency to the latest version and resolve class conflicts

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

run starrocks_admit_test

please rebase main. I just merged the iceberg upgrade patch

run starrocks_admit_test

[FE PR Coverage Check]
:heart_eyes: pass : 1 / 1 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/AlterTableStatementAnalyzer.java
1
1
100.00%
[]

run starrocks_admit_test

[FE PR Coverage Check]
:heart_eyes: pass : 1 / 1 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/AlterTableStatementAnalyzer.java
1
1
100.00%
[]

[FE PR Coverage Check]
:heart_eyes: pass : 1 / 1 (100.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/sql/analyzer/AlterTableStatementAnalyzer.java
1
1
100.00%
[]

run starrocks_admit_test

run starrocks_admit_test

run starrocks_fe_unittest

run starrocks_fe_unittest

run starrocks_admit_test

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)

run starrocks_admit_test

[FE PR Coverage Check]
:heart_eyes: pass : 0 / 0 (0%)


[casclib] Update to 2024-06-05

[x] Changes comply with the maintainer guide.
[x] SHA512s are updated for each updated download.
[x] The "supports" clause reflects platforms that may be fixed by this new version.
[x] Any fixed CI baseline entries are removed from that file.
[x] Any patches that are no longer applied are deleted from the port's directory.
[x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
[x] Only one version is added to each modified port's versions file.

Instead of patching, it could just use -DCMAKE_REQUIRE_FIND_PACKAGE_ZLIB=ON.

Interesting, I did not know about that cmake feature


release v0.1.0

We will release v0.1 recently.
Changelogs

code generation

*.wit format supporting

func
record
variant
enum
resource

backend

rust

runtime import/export
instance import/export

check command

done


I don't know what do to ? Autosub not running

console says:Traceback (most recent call last):
File "C:\ProgramData\Blackmagic Design\DaVinci Resolve\Fusion\Scripts\Utility\auto-subs.py", line 713, in
searchMediaPool() # Search media pool for possible templates
^^^^^^^^^^^^^^^^^
File "C:\ProgramData\Blackmagic Design\DaVinci Resolve\Fusion\Scripts\Utility\auto-subs.py", line 627, in searchMediaPool
recursiveSearch(folder)
File "C:\ProgramData\Blackmagic Design\DaVinci Resolve\Fusion\Scripts\Utility\auto-subs.py", line 648, in recursiveSearch
itemType = item.GetClipProperty()["Type"]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

Looks like you skipped step 1 in the tutorial
https://www.youtube.com/watch?v=Q-Ud4ZAWH6o


Improve the job retry logic

Recent unity versions are not being published to docker hub anymore due to our retry logic. Right now, Windows based images are failing due to https://github.com/game-ci/docker/issues/154 and we are reaching the number of retries limit for a given unity version, which prevents other working targets to be published.
https://game.ci/docs/docker/versions
Here are the currently failed images:

It is still unclear what is going on with the retry logic because some recent images succeeded to build at least the ubuntu based images, but others didn't.
Example of success: editor-2021.2.9f1-0.17.0
This version doesn't seem to have hit the current issue

Example of failure: editor-2021.2.11f1-0.17.0
This specific version seem to have hit the retry logic problem.

Will have a look at this tonight. But I don't think there's anything wrong with the retry logic. It's just a commit that landed after the hub was already published for that version.
Ultimately we could make the workflow check out the the tag version of the repository instead of main, but that will bring a few more challenges with regards to performing fixes to the build flow.

@GabLeRoux @webbertakken  unity 2020.3.28 and unity 2020.3.29 images are not available, would you please check this issue?

I'll have time for this next weekend.

To update here, requested versions in above comments were published successfully.
https://game.ci/docs/docker/versions
We identified and fixed the root cause of the failing builds.
The current implementation of the retry logic is probably fine.
Before we close this issue, maybe we should answer this question:
What happens if it fails to build the windows based images of a given version, will the ubuntu based images still be published?
If answer is yes, than we can definitely close this issue :)

Consider Jobs schedule Builds, where Jobs represent dockerRepoVersion-EditorVersion and Builds represent a baseOs-targetPlatform for a Job.
The way I ended up implementing this is that each Job schedules all Builds, thus: all targetPlatforms across all baseOses for that dockerRepoVersion and unityEditorVersion.
Together they share the same buildQueue and buildFailureCount. The setting currently look like this:

The retry logic itself was never really "broken". We just added windows-based builds also be rescheduled and reported in, in #36, #37.

Thanks for the detailed explanation <3
Closing this as I don't think we need to change anything for now :)


Seeder class path wrong with wrong namespace

Hello,
When I run,
php artisan make:module:seed [SLUG] [NAME]
this command generates files in \Modules\ModuleName\Database\Seeds\App\SeedClassName.php
Code in SeedClassName.php
<?php

namespace App\Modules\ModuleName\Database\Seeds;

use Illuminate\Database\Seeder;

class App\SeedClassName extends Seeder
{
    /**
     * Run the database seeds.
     *
     * @return void
     */
    public function run()
    {
        //
    }
}

I don't know why App is prefixed and created file in Database\Seeds\App <-- this is wrong file structure.
Please take a look. Thanks.

See #316


Minor doc issue with LimeTabularExplainer

The doc string is poorly rendered here: http://lime-ml.readthedocs.io/en/latest/lime.html The documentation shows:

kernel_width – kernel width for the exponential kernel.
None, defaults to sqrt (If) –
verbose – if true, print local prediction values from linear model

The None is a part of the kernel parameter. I don't know the Sphinx rendering process, I'm guessing the line here is in error (possibly an extraneous carriage return?): https://github.com/marcotcr/lime/blob/master/lime/lime_tabular.py#L126
Additional rendering errors occur for:

https://github.com/marcotcr/lime/blob/master/lime/lime_tabular.py#L228
https://github.com/marcotcr/lime/blob/master/lime/lime_tabular.py#L241

Fixed it, thank you.


feat: add cert delivery test

Description
Run cert delivery test as part of topos integration tests.
Fixes TP-815
PR Checklist:

[x] I have performed a self-review of my code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] I have added or updated tests that comprehensively prove my change is effective or that my feature works

Needs rebasing.


uplink and store freshening

About the PR

various changes to store/uplink internals after some tech bloat made it smelly:

adds helper functions for getting the name and description of a listing
fixes admin logs sometimes not displaying the right name (Fixes #21812 )
hides refund button if stores do not support it, instead of disabling it (no more visible refund on uplink)
updates ListingData with new ProtoId and datafield stuff
removes the horrid refresh button and makes listings update timers in real time
fixes strange comparisons using listing names to determine if something was in stock
changed roundstart purchase delays to be serialized as a timespan instead of integers representing minutes (insert AVGN "what were they thinking")
adds localization for "out of stock" text
misc. cleanup

Media

https://github.com/space-wizards/space-station-14/assets/98561806/2cf47b41-694d-4dc5-b50c-73c89407d9fd

[x] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Breaking changes

Changelog

no cl no fun

hold on im about to go make smugs day

Square buttons look cringe.
Keep them stylized :tm:

Square buttons look cringe. Keep them stylized ™

unfortunately that's simply an incorrect opinion. My condolences.

The stylized buttons help visually separate the different tabs. They look significantly better than the square side buttons IMO

I like the stylized corner on the right, but dislike it on the left. Could it be styled to just have the top-right corner slanted? Would kinda look like physical folder tabs.

unfortunately that's simply an incorrect opinion. My condolences.

https://youtu.be/jY4Zh-Dw2iY

The stylized buttons DO look better here, they add some visual variety and with the square buttons everything just looks flat :/


Improve checks for connect in<EMAIL_ADDRESS>

I found that, with the current definitions, the return values of mapStateToProps, mapDispatchToProps and mergeProps are not checked against the wrapped component as I would have expected.
Example
Given a component that takes a string prop, trying to pass a number for that prop in mapStateToProps fails as expected:
  type Props = {
    str: string
  };

  class Com extends React.Component<Props> {
    render() {
      return
{this.props.str}
;
    }
  }

  type State = {num: number, str: string};

  const mapStateToProps = (state: State) => {
    return { // error
      str: 123
    }
  };

  connect(mapStateToProps)(Com);

But soon as a property from state or a selector function is used instead of the number literal, no errors are detected anymore:
  type Props = {
    str: string
  };

  class Com extends React.Component<Props> {
    render() {
      return
{this.props.str}
;
    }
  }

  type State = {num: number, str: string};

  const mapStateToProps = (state: State) => {
    return { // no error
      str: state.num
    }
  };

  connect(mapStateToProps)(Com);

Same basically holds for the other parameters of connect. There are also cases where unknown props are not detected correctly.
As a result misspelled props or selector functions with incompatible return values go unnoticed.
I've created a branch with some examples that I'd expect to result in errors, but which pass except for simple cases:
https://github.com/flowtype/flow-typed/compare/master...tf:redux-selector-problem-2
I deliberately did not put in $ExpectError comments, so that the current error messages are visible. The Travis build is quite noisy since all of the tests for the flow_v0.54.x-v0.61.x and flow-v0.62.x variant are failing on master, but here's the relevant part:
https://travis-ci.org/tf/flow-typed/jobs/367131347#L1834
Proposed Solution
Looking at the way connect is defined at the moment, the main problem IMO is that the return value of  mapStateToProps etc. is not directly related to the wrapped components prop types:
  declare type MapStateToProps<S: Object, SP: Object, RSP: Object> = (state: S, props: SP) => RSP;

  declare export function connect<
    Com: ComponentType<*>,
    S: Object,
    DP: Object,
    RSP: Object,  // <== no direct relation to Com
    CP: $Diff<OmitDispatch<ElementConfig<Com>>, RSP>
    >(
    mapStateToProps: MapStateToProps<S, DP, RSP>,
    mapDispatchToProps?: null
  ): (component: Com) => ComponentType<CP & DP>;

At least when no mergeProps function is present, mapStateToProps and mapDispatchToProps should only be allowed to return valid props for the component. This PR therefore makes the following changes:
  declare export function connect<
    P: Object, // <==
    Com: ComponentType
, // <== Introduce a type variable for the props of Com
    S: Object,
    DP: Object,
    RSP: $Shape
, // <== Allow only those props in state props
    CP: $Diff<OmitDispatch<ElementConfig<Com>>, RSP>
    >(
    mapStateToProps: MapStateToProps<S, DP, RSP>,
    mapDispatchToProps?: null
  ): (component: Com) => ComponentType<CP & DP>;

See also http://sitr.us/2015/05/31/advanced-features-in-flow.html#shapet.
If mergeProps is present, mapStateToProps and mapDispatchToProps are still allowed to return arbitrary data. Only the return value of mergeProps itself has to match the shape of the wrapped component's props.
The PR contains more valid and invalid examples.
The test failures either come from the react-redux_v5.x.x/flow_v0.54.x-v0.61.x/ directory, which is not altered by this PR or Flow 0.62, which appears to have problem importing ElementConfig from react. For 0.63 and above tests pass. This problem also exists on master.

I'll do some more real life testing in one of our projects. Just wanted to submit this early to get some feedback.

Sorry for not getting back earlier. I'll try to look into villesau's comments.

@tf have you had time to check it out?

With the new Flow and fixed typings it's enough to just instantiate the component to get the (misleading) error: https://github.com/flow-typed/flow-typed/pull/3035/files#diff-a8524c9f8ed49a21b3ff85e6a1b27499R579


Top 50 DBMS interview questions

@AkashSingh3031 : This is the Top 50 DBMS interview questions

@AkashSingh3031 for this set I dont have any images, from next onwards will save images and include that.

Can you add example and images if possible
@AkashSingh3031 for this set I dont have any images, from next onwards will save images and include that.

Ok
Try to add resources in a topic wise folder


style: simplify some statements for readability

Closes #1242

@BurntSushi are you open to this change?


Set frezon sell price to 0

About the PR

There are multiple atmos bugs that currently allow essentially infinite frezon generation.
#14287
#13748
Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

Changelog

:cl:

tweak: Frezon prices have tanked due to a recent influx of supply.

This change is odd.
I don't think it's a good idea to make frezon worthless over bugs affecting atmos as a whole.

This change is odd. I don't think it's a good idea to make frezon worthless over bugs affecting atmos as a whole.

this

the issue is greatly exaggerated here, #14287 isn't even a bug, it's just a property of the frezon mixing reaction, and #13748 doesn't allow for accelerated trit production either since even without that bug you would still be able to just make a bigger mix chamber

Gas sell prices have always been quite strange. Firstly, all gases are infinite in supply, so their prices should theoretically be nothing. I know that trit and frezon need a mix chamber, but any tech worth their salt can set one up pretty easily. As such, from that point, you can produce basically infinite money in a system that doesnt even involve cargo.
My tl;dr is that atmos money is too easy and pretty lame for cargo. This nerf is fine. Atmosheads stay mad.

the price at least shouldn't be 0, should be maybe around 1/mole instead

This is a terrible solution... should instead fix the bugs that allow for infinite production instead

Gas sell prices have always been quite strange. Firstly, all gases are infinite in supply, so their prices should theoretically be nothing. I know that trit and frezon need a mix chamber, but any tech worth their salt can set one up pretty easily. As such, from that point, you can produce basically infinite money in a system that doesnt even involve cargo.
My tl;dr is that atmos money is too easy and pretty lame for cargo. This nerf is fine. Atmosheads stay mad.

Pretty sure this is supposed to be a temporary change until the bugs regarding frezon production are fixed.

I understand that, but tbqh atmos money making has always been meta for cargo, which is really lame considering how uninvolved it is on Cargos side. I get that it's departmental cooperation, but cargo really just has to bug atmos techs and then just wait. In return, they get massive returns at low cost and effort on their part.

if youre going to do this which you shouldn't because this is dumb then just remove gas selling entirely

I understand that, but tbqh atmos money making has always been meta for cargo, which is really lame considering how uninvolved it is on Cargos side. I get that it's departmental cooperation, but cargo really just has to bug atmos techs and then just wait. In return, they get massive returns at low cost and effort on their part.

 Gas miners are just free money, considerint a decent setup can get you enough to offset the cost of a canister to package more.

ok yes cargo having infinite money is bad but at least this is higher effort than them selling vending machines and stuff and also gives atmos something to do in game. id rather just have it bugged while we wait for fixe to rounding errors

there are no rounding errors, i explained it in the issue, the frezon burn reaction is just apparently wrong?

and no, atmos usually make gases specifically to sell, i don't think you'd often see atmos making trit, frezon, or N2O for the sake of it

This is a PR made to get a reaction and not propose a proper solution to the problem (i.e. fixing bugs.)
Do not make a point by pulling a knife, make a point with your words.


Move the experimental frontends into a separate crate, so that when not using them they don't take several minutes to compile (and indirect dependencies).

Move the experimental frontends into a separate crate, so that when not using them they don't take several minutes to compile (and indirect dependencies).
This saves several minutes (and MBs of data) on compilation time both when running tests in this repo, but also when using the sonobe lib as a dependency in external repos.
This solution was suggested by @ed255 when talking about this.

Indeed, that's a good point. This was initially done at https://github.com/privacy-scaling-explorations/sonobe/pull/141 but the issue is that even if a frontend was 'not used' by not using its feature, it's dependencies were still being imported (and the dependencies of the dependencies, taking long minutes and MBs of data), when running tests but also when using Sonobe as external dependency.
With the separation into a different subpackage for the experimental frontends done in this PR, the users of the lib that don't use any of the experimental frontends will not get impacted by those dependencies that are in fact not used in that case, and only in the cases where the experimental frontends are specifically used those dependencies will get used.
The recommended frontend is using arkworks (directly implementing the FCircuit trait), and the other experimental frontends add overhead when generating the witness which makes the folding step slower.

oh, okay; now I remember similar issue I had with private repo dependency in a workspace causing problems for every member crate, even for those, that didn't use it (even indirectly); afair a workaround it was to use some dummy patching, but in Sonobe case I totally understand and support your final decision - thanks!

Will wait till https://github.com/privacy-scaling-explorations/sonobe/pull/169 is merged, and then will rebase this PR (#168) to main (once it includes #169) and deal with the git conflicts in this branch (#168).

Let's just merge this @arnaucube as I want to wait for Janabel to confirm that the PR works prev to merge it.


pip source plugin

See original issue on GitLab
In GitLab by [Gitlab user @sstriker] on Oct 20, 2017, 16:07
While we have a pip build element, we do not have an element to fetch packages and track them.
A source element that would effectively leverage https://pip.pypa.io/en/latest/reference/pip_download/#overview would be a good counterpart to the build element.  It would allow users to help fetch and track the dependencies of their python code much more conveniently.

In GitLab by [Gitlab user @tristanvb] on Oct 20, 2017, 18:45
Hmmm, interesting.
I can see the convenience, but I worry this might have similar issues as #10 (dpkg source)
Is it practical or even possible for a pip source plugin to comply to the restraints, which are basically that with the same source configuration, you will always provide exactly the same data ?
Even if it's semantically possible, does PyPI make any guarantee to keep providing every version of every package ever distributed ?
I worry this might be unsafe, and that instead it makes more sense to use a hand full of pip build elements with git sources.

In GitLab by [Gitlab user @sstriker] on Oct 21, 2017, 20:05
Well, we could store the hash of what was downloaded by pip download as the ref.  Otherwise its following requirements, I'd argue using https://pip.pypa.io/en/stable/reference/pip_install/#requirement-specifiers.
I think even if PyPI doesn't make that guarantee, there are ways to ensure you keep a copy of every package ever used.  Either using a product like Artifactory, or through some other means.

In GitLab by [Gitlab user @tristanvb] on Oct 22, 2017, 10:39
So this is a bit of a slippery slope so to speak, we're going to see this for JS npm and for Rust's crates.io too.
There is another problem with this, too:

One element decides to use a pip source, because yay, it's easier to provide all the specific python dependencies for that element
Another element decides to use pip source, same reason
Both elements might have common pip source originating dependencies, at different versions

Now we have file overlaps
Now we are no longer certain which version of a pip dependency will be present on the system, and shared by all the elements which depended on it via pip

To be clear, I dont think we should block this; but I think we should consider this as an addition to the external plugins repo that [Gitlab user @jonathanmaw] is working on. The rationale for this is:

As mentioned, it may require some third party artifactory or such to ensure availability of what we depend on
I think the above mentioned scenario with version uncertainty and overlaps will occur if the pip source is really going to be convenient, and allow a python app author to "get all their dependencies in one go"
We should be encouraging our preferred workflow in the main buildstream repository, which is hopefully a single method to do each thing (providing two user stories for using python dependencies means users dont have a sane default, but instead they have a pesky "choice" getting in the way, which I think is undesirable).

In GitLab by [Gitlab user @samthursfield] on Oct 23, 2017, 16:34
There are a few tools which can produce a set of PyPI dependencies given a package name and version. What about using an external tool to generate and update the relevant .bst files?
We researched this in Baserock a while back, and while the relevant tool has bitrotted, the approach worked pretty well and could probably be largely reused. It's documented a bit here; basically it worked by running pip install $package in a virtualenv and then running pip freeze to get a list of requirements. This could be slow if some dependency decided to compile lots of C++ code, but it was pretty reliable.
Various distros have something similar, e.g. pypi2nix, guix import, pypi2deb, etc.
I admit this isn't as nice as being able to do bst track, but I feel like importing from package repos has way more edge cases than tracking upstream source repos, and we perhaps shouldn't treat them as interchangable activities.

In GitLab by [Gitlab user @juergbi] on Feb 25, 2018, 18:39
In my opinion, a simple PyPI source plugin that doesn't include dependencies would already be very useful for tracking. This would avoid the file overlap issue.
Dependency handling would be nice, of course, but that might indeed be better done using an external tool. Theoretically, it would also be possible to generate .bst files in a source plugin and use that in a junction. However, given the complexity, an external tool may be a more sensible approach.

In GitLab by [Gitlab user @samthursfield] on Feb 26, 2018, 10:18
[Gitlab user @jmacarthur] prototyped such a tool already : https://gitlab.com/jmacarthur/python-to-element

In GitLab by [Gitlab user @LaurenceUrhegyi] on Jun 1, 2018, 14:42
I think this is dependent on https://gitlab.com/BuildStream/buildstream/issues/381

In GitLab by [Gitlab user @knownexus] on Oct 8, 2018, 13:46
Is this still an issue? A quick glance at buildstream/plugins/sources suggests we have a pip plugin?

In GitLab by [Gitlab user @toscalix] on Oct 8, 2018, 13:52
assigned to [Gitlab user @sstriker]

In GitLab by [Gitlab user @toscalix] on Oct 8, 2018, 13:52
Assigned to [Gitlab user @sstriker] to evaluate if this ticket should be closed.

In GitLab by [Gitlab user @tristanvb] on Jan 17, 2019, 00:19
This is definitely exactly the issue we resolved with the whole SourceTransform discussion which turned into a new feature on the Source class giving sources access to previously staged sources at track time.
[Gitlab user @cs]-shadow implemented all of this along with precisely a tested pip plugin to demonstrate that the mechanics work.
Closing this rusty old issue :)

In GitLab by [Gitlab user @tristanvb] on Jan 17, 2019, 00:19
closed


1.0.0

I know it doesn't mean much in a context like this, but rust-g has been battle tested in many major servers and likely will not receive many backwards incompatible changes for a bit. Would be nice to move to 1.0.0 to better communicate what is happening in the updates.

ok

will move to 1.0.0 after 0.8.0, as an empty no changes release


Allow arguments to {{mount}} template keyword and mount routing helper

The following was discussed at the Ember Core Team F2F in January:

The {{mount}} template keyword should allow normal handlebars style hash arguments. The router DSL style should also allow some sort of API to supply parameters too.

Still TBD:

What API should the mount routing helper support for accepting parameters?
Are arguments set directly on the engine instance?
How can an engine declare which properties are writeable?

Out of curiosity, what are some use cases this is attempting to solve? My perspective is that passing in values like this would be akin to passing state which I assumed is what we had service dependencies for.

@trentmwillis Our use case for this would be for the dashboard of the CMS we're developing.
When the dashboard loaded we would retrieve a list of widgets that needed to be displayed, we would then loop through each of the widgets mounting them onto the dashboard. When mounting the widget, we would also pass through some initial config/data for the widget to use.
The data passed through could be some initial data to display, preventing each widget needing to make a separate request to the server for data.
While simplified for the sake of brevity, we would have something like this:
{{#each dashboardWidgets as |widget|}}
  {{mount widget.name config=widget.config data=widget.data}}
{{/each}}

@mike183 is there a reason why a service couldn't mediate that transfer of information?

@trentmwillis Usually the need for this comes down to a single engine being used in multiple contexts within the same app. Passing a parameter to the engine could configure its context.
Take for example a routable "blog" engine which is used to create a "design" blog mounted at /design and a "developer" blog mounted at /dev. Even if a common service provides data for both blogs, each blog instance will need to be passed some configuration parameters to properly filter data from that service.

@trentmwillis The dashboard widgets would be developed by third parties so it would just be a case simplifying the development of the widgets and reducing boilerplate code.
@dgeb That's a pretty interesting use case, I'd never considered using engines in such a way.

a single engine being used in multiple contexts within the same app.

Okay, that use case makes sense to me, since it doesn't make sense to have the branching logic for multiple configs within the Engine.

My concern is that you could introduce runtime dependencies making tree shaking and lazy loading more difficult.
export default Ember.Component.extend({
  geo: Ember.inject.service('geolocation')
})

{{mount "blog" (hash geo=geo)}}

this already solved 🎉
can we close this @dgeb @rwjblue ?


Closes https://github.com/aws/aws-lambda-go/issues/118

I am unfamiliar of tools to make sure the mapping between the JSON and struct is 100%. So it was a manual process.

resolved in #211


feat(trusted claim issuers): require trusted claim types on claimissuers

Methods that modify default trusted claim issuers for a token now require passing Claim Types for
which that issuer is trusted
BREAKING CHANGE: - TrustedClaimIssuers.set and TrustedClaimIssuers.add now require an array of
TrustedClaimIssuer objects (each with an identity and an array of ClaimTypes)

:tada: This PR is included in version 3.0.0-alpha.1 :tada:
The release is available on:

npm package (@alpha dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 3.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Redirect from http to https better than in the web.config

Check out #184
This fixes the issue of http://beta.nhs.uk/finders redirecting to https:///finders
However, it is clearly not a great solution from the POV of using a different (sub)domain name to serve the site from. It also means that all environments do the same redirection.
Ideally the http(s) redirections are handled by the infrastructure rather than the application but it would appear the web.config isn't the best place to do that.
This issue is about implementing a better/longer term/more scalable/more suitable solution to having the application only served over https.

Since moving away from Azure PAAS and using Docker instead this issue is void. The redirection from http to https is now done within the infrastructure and the application doesn't have to concern itself with it.


Encode space character

Hi.

Closing because of no response. If this is still an issue for you, please respond and I will reopen.

It does not matter that which conversion options we use. Space characters are ignored and not converted in any situation.

@Tokenizer94  If you send me an example of your quill json, I can investigate it.

Closing because of no response. If this is still an issue for you, please respond and I will reopen.


Fix double chain subscriptions.

Currently if you use map() (and probably other functions) there are 2 listeners added to the parent listenable
One in constructor, and another one as soon as mapped listener gets it's own subscription in addListener (the check is for hasListeners which is false at the time, but the chain is already set up).
After mapped subscription is removed, the second chain listener is properly removed but the first one remains.
This PR fixes the issue described above.

Sorry for the delay. Awesome find. thanks a lot


Test cache store dependencies in isolation

FTR, the reason why TravisCI is red is because by isolating cache store dependencies in each test suite run, we are successfully exposing/reproducing this existing bug https://github.com/kickstarter/rack-attack/issues/355.


User-Auth

Things added

Adding user creation
user can now log in and out

views.py signout function and recipes does not contain docstring

The code seems to be working just fine.

However, the layout is a bit confusing. Even though this is just an initial design, I feel like I should still point it out.

However, the layout is a bit confusing (or maybe it's just me). Even though this is just an initial design, I feel like I should still point it out.

However, the layout is a bit confusing (or maybe it's just me). Even though this is just an initial design, I feel like I should still point it out.

It's django default but if you want me to change it I can do that.

It's django default but I can change it if you want

I created a new registration form

Continue on Branch User-Auth


Subjects are duplicated in results from query on Specimen.File where File is associated with more than one specimen

Description
Where a file is associated with more than one specimen for the same Subject, queries on ResearchSubject.Specimen.File return the Subject multiple times, instead of once. This occurs in part where File is denormalized to other specimens - and that is how the problem was originally identified.
However, there are cases where the same file may show up genuinely within the same Subject.
To Reproduce
See notebook Query by PDC filename
Expected behavior
Each Subject and its contents should be returned only once.

Using the new 3.0 release endpoints, if you wanted results to be returned by Subject, you would search from the Subject endpoint rather than the Specimen one. Specimen will always return by specimen, not by subject.


refactor: clean up oci_pull

The following changes are made to simplify the implementation

remove templated json logic
avoid running actions for simple files.
rename variables to remove lines

waiting for #367 and #368


move app name to ENV.APP_DISPLAY_NAME

Moved app name (Epic Notes) to ENV.APP_DISPLAY_NAME. Haven't added docs yet but let me know if this is a good approach and I'll go do that.
(noticed ENV wasn't available in the tests but wasn't a big deal)
Test Plan

Checklist

[x] Tests updated
[ ] Docs updated

Screenshots

Sorry for dragging my feet on this. The reason is I really prefer to avoid doing things like this generally. In the real apps I build, I never want something like this to be a config-based thing. Ultimately strings like this should go in localization strings, but in apps where I'm not localizing things I prefer to inline them rather than have environment variables.
I realize this is a bit of a pain when you're creating a new Epic Stack app to have to go through and update a bunch of hard-coded stuff, but I think it's better than leaving a bunch of environment variable references.
Sorry!

Could this be a use case for a code mod to update app name?

I thought about that, but it's really just in a bunch of strings and so a simpler find/replace thing would probably be better. I'm just concerned that it would be pretty brittle.


Copy the file and remove the original

Hi :wave:,
There is an issue running setup-minikube in self-hosted GitHub actions runners due to the tmp folder being on a different partition:
Error: EXDEV: cross-device link not permitted, rename '/runner/_work/_temp/631b8ac3-0772-449c-b657-cb5e6ebd055e' -> '/home/runner/bin/minikube'

It's related to this bug:

https://github.com/actions/toolkit/issues/706

The underlying io.mv tries to rename the file to the new location which does not work across partitions.
To workaround that issue, this commit makes the code io.cp the file and io.rmRF the original.
Kind regards,
Stephen

@stephendotcarter thank you for this contribution


Fixes transportcc padding

If padding is set in the header, then the last octet of padding is set
to be the length of padding itself. This is consistent with the usage of
"zero padding" in SR.

If the padding bit is set, this individual RTCP packet contains
some additional padding octets at the end which are not part of
the control information but are included in the length field.  The
last octet of the padding is a count of how many padding octets
should be ignored, including itself (it will be a multiple of
four).

https://tools.ietf.org/html/rfc3550#section-6.4.1
Reference issue
Fixes #52

@LittleLightLittleFire nice work! This LGTM, if you just add a body to your commit message it should pass the linter!
Sorry for the frustration, but it helps debugging in the future to have the verbose git log.

@Sean-Der Cheers, all done.

@LittleLightLittleFire This branch cannot be rebased due to conflicts

@adwpc Looks like CI doesn't like your commit message (no body) on the merge. I force pushed it again after rebasing, would make cleaner history anyway.

LGTM


Update Github CI/CD

Summary:
Setting up cross-platform integration tests
(this will get spam updated as I test different things, code owners should unsubscribe if it is annoying, will share for final review when actually ready)
Differential Revision: D51506574

Superseded by:
https://github.com/facebookincubator/TTPForge/pull/446


Sync ad api draft

Description

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[ ] I've confirmed the contribution guidelines.
[ ] The PR follows the pull request guidelines.

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

[ ] The PR follows the pull request guidelines.

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

[ ] There are no open discussions or they are tracked via tickets.

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

I made a mistake in the target repository.


Innovator Artillerist Tiny Cannon power should use bonus action not action

Running on dev branch currently.
Commit 6ba3eba changed the cannon power to use an Action. This is correct for summoned cannons, but this power is also re-used for the Tiny Cannon. It therefore has an unintended side effect of causing the Tiny Cannon to use the player's main action to activate, when it should instead be a Bonus Action.
Not too familiar with tricks in the code, but I guess this might require duplicating the action definition for a "tiny" version that uses a bonus action.

shit. had to duplicate a lot of stuff but fixed.


PVP - versioning

Looks like that your package(s) are following the Semantic Versioning -scheme. That's great, but it would be even better if it followed the Package Versioning Policy (PVP). In a nutshell, PVP has the same principles as the SemVer, but it talks specifically about Haskell, and has different meaning for the version digits: major1.major2.minor.patch. Even that bumping the versions according do SemVer doesn't violate PVP, it is unnecessarily over-conservative, and thus might be inconvenient for the downstream users. For example Stackage LTS allow only the minor (the third digit) updates inside major LTS version.

From the homepage of Hackage

Guidelines for Hackage Packages:

All packages should follow the Package Versioning Policy (PVP).

cc @bergmark @hvr

I've always found pvp to be overly liberal and awkward to increment. I'm also curious how semver could be inconvenient for users. Have there been documented cases of this?

@fosskers the inconvenience is that everyone (including the tooling) expects PVP-version structure and sets versions bounds accordingly. If a package violates this assumption it results incorrect versions bounds which thwarts the primary purpose the PVP was created for.

PVP is clearer to me after reading the page linked by @phadej . That said, having two numbers for major version (A.B) seems superfluous, and I claim through anecdote that many packages sit needlessly at 0.x for their lifetimes. If that's true, then let's just do away with the leading 0.
PVP has three incrementation rules. To directly compare PVP to SemVer (MAJOR.MINOR.PATCH), we have:

Increment A.B if there is a breaking API change (SemVer: Increment MAJOR)
Increment C is there is a non-breaking API change (SemVer: Increment MINOR)
Otherwise, increment the other components in any way (SemVer: Increment PATCH or pre-release)

From the PVP spec:

A package version number should have the form A.B.C, and may optionally have any number of additional components...

Meaning a package could have any number of integer (stated later) components over 3. Does Stackage expect exactly 4?
If tools only need to assume 3, is there real harm in adhering to SemVer? I see that versions was successfully added to today's nightly, despite being SemVer.

Related comment: https://github.com/jswebtools/language-ecmascript/issues/60#issuecomment-70073959

A casual glance of the current LTS index shows a non-trivial number of packages not following PVP as defined here and in the linked document above. I see some with just A.B and no C, even.

The literal number of components does not signify which version scheme is followed, it's perfectly fine to go 1 -> 1.1 -> 1.1.1 -> <IP_ADDRESS> (except for complicating usages of the MIN_VERSION macros).
And since we are mentioning LTS, any package following semver would stop being upgraded in LTS as soon as they make a non-breaking api change since LTS also assumes that packages follow the PVP.

any package following semver would stop being upgraded in LTS as soon as they make a non-breaking api change since LTS also assumes that packages follow the PVP

True, but that might not be the end of the world. People using LTS realize they're not getting the bleeding-edge, and they have to live with that.
I would switch to PVP in a heart beat if I could be convinced it was demonstrably superior to SemVer.

@fosskers It's not relevant whether the PVP is superior to SemVer or vice-versa for the matter at hand: Hackage uploaders are asked to follow the common guidelines, and those clearly state that uploaded packages are expected to follow the PVP. You don't have to like the conventions, but you are nevertheless expected to follow them for the sake of the community. When in rome, do as the romans do... :-)

I would switch to PVP in a heart beat if I could be convinced it was demonstrably superior to SemVer.

The PVP is a superset of SemVer.  Make your SemVer version, then concatenate the prefix "0." (or "1." or whatever makes you happy) onto the front.  The important point though is that most of the value of both PVP and SemVer comes from network effects.  It's a communication standard between developers. And it just so happens that in the Haskell community the PVP is the standard.

The PVP is a superset of SemVer

Not entirely true, as SemVer has semantics for rerelease and metadata components, but I see what you mean.

Thanks for the feedback everyone, I'm pondering my course of action.

Not entirely true, as SemVer has semantics for rerelease and metadata components, but I see what you mean.

@fosskers Yes, you're right.  But I believe Cabal files do not support SemVer's pre-release and metadata components, so they shouldn't be a part of the discussion in this context.
Also, your package description says that SemVer "has the best constraints on comparisons".  I would argue that in the presence of a pre-release version, SemVer's comparison method is more complex and less intuitive than that of Cabal PVP-style versions.
But again, these are just side notes to the most important point that most Haskell package authors expect the PVP.


Unable to Deploy Any New Subgraph

Do you want to request a feature or report a bug?
A Bug
What is the current behavior?
Not able to deploy new subgraphs
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Not able to deploy any kind of new subgraphs, not even if it is the default one which gets created with the init command. The deployment command does not provide any helpful message to debug/look into the root cause of failure, just this message -"Could not deploy subgraph on graph-node, please try again".
Here are the steps to reproduce the issue:

Create a new subgraph from dashboard
Initialize like graph init --studio <INSERT_SUBGRAPH_SLUG>
Deployment steps

❯ graph auth --studio <INSERT_DEPLOY_KEY>
Deploy key set for https://api.studio.thegraph.com/deploy/
❯ cd studio
❯ graph deploy --studio <INSERT_SUBGRAPH_SLUG>
✔ Version Label (e.g. v0.0.1) · v0.0.1
  Skip migration: Bump mapping apiVersion from 0.0.1 to 0.0.2
  Skip migration: Bump mapping apiVersion from 0.0.2 to 0.0.3
  Skip migration: Bump mapping apiVersion from 0.0.3 to 0.0.4
  Skip migration: Bump mapping apiVersion from 0.0.4 to 0.0.5
  Skip migration: Bump mapping apiVersion from 0.0.5 to 0.0.6
  Skip migration: Bump manifest specVersion from 0.0.1 to 0.0.2
  Skip migration: Bump manifest specVersion from 0.0.2 to 0.0.4
✔ Apply migrations
✔ Load subgraph from subgraph.yaml
  ....
✔ Compile subgraph
  Copy schema file build/schema.graphql
  ....
  Write subgraph manifest build/subgraph.yaml
✔ Write compiled subgraph to build/
  Add file to IPFS ....
  Add file to IPFS ....
  Add file to IPFS ....
✔ Upload subgraph to IPFS

Build completed: <BUILD_ID>

✖ Failed to deploy to Graph node https://api.studio.thegraph.com/deploy/: Could not deploy subgraph on graph-node, please try again.

What is the expected behavior?
The deployment should go through and a deployment url & subqueries should be o/p after deploy command

✖ Failed to deploy to Graph node https://api.studio.thegraph.com/deploy/: Could not deploy subgraph on graph-node, please try again.
Subgraphs are not deployed.

Hello, @aayush4vedi

Go this URL: https://thegraph.com/hosted-service/
Sign in by Github
Create Subgraph
Deploy graph deploy --product hosted-service username/subgraph

Thanks both, please reach out on Discord for support, closing this as it doesn't appear to be a Graph Node issue