Define criteria for listing clients on NuGet.org’s package details page

For reference, see this pull request from Paket as an additional tab: https://github.com/NuGet/NuGetGallery/pull/4437

why should there be any criteria aside from being an actual working client?  as stated in the last pr maven lists multiple clients. I don't understand the reluctance here at all.  can you maybe explain your concerns?  if nuget change a protocol and that break Paket which in turn makes the command displayed not correct how does that affect nuget.org ?

@falfaddaghi I will admit that I don't have a well-thought out response yet, so please consider this as me just thinking out loud - curious what you think?

Once we agree that a particular experience is core to the .NET developer experience (security, platform support, etc.) - should we mandate that the client support that? How do we reason with the urgency around supporting a particular experience - wait for everyone to be ready, etc.?

Our data currently shows that NuGet.org is accessed by 10s of different kinds of clients, if not more (hard to know for sure, since we don't have a contract for the client to share a well know name and version :( ). What is the objective criteria we can use here to triage requests?

We will almost certainly need to do additional more UX work to give the user more information so they can make an informed choice about who supports the client, what scenarios work, what don't, and so on.

Trying to maintain so much control over the .NET developer experience is what has driven so many .NET developers away in the first place. The problem is that there is no one size fits all experience. We need to be able to make and use tools that fit our particular needs. For some that is out of the box one stop shopping, for others it's customizing to reduce the burden of certain kinds of common developer tasks (this is what Paket does really well).
We are a small team with many clients and so hundreds of .NET projects. Keeping them up to date and in sync with Nuget was a maintenance nightmare. However, the standard Nuget client might be just fine for a team focused on one single or a few products.
Security is important and I think all clients should be made to be secure by enforcing a secure protocol. However, I think mandating platform support goes too far. If it works for the people who opt in to use it what's the problem? There's nothing stopping you from using the standard Nuget client in some projects and Paket in others where the dependency burden has become overwhelming.

@unniravindranathan I'll try to reply my thoughts in line:

Once we agree that a particular experience is core to the .NET developer experience (security, platform support, etc.) - should we mandate that the client support that? How do we reason with the urgency around supporting a particular experience - wait for everyone to be ready, etc.?

Security, IMO, isn't an "experience" as much as a "platform requirement". Any client with decent support will adjust to your security concerns. I think that should be eliminated from criteria - if you have an API, and a client uses it, security should be handled (barring stupidity in the client - and major security issues, I agree, should be enough to not be listed).
That being said -
I think dictating that any specific experience is "core to the .NET developer" only restricts the .NET developers you will attract.
Make the experience better, and people will use it. That's why Paket, as an example, exists in the first place. The "official" client has significant issues with the workflow of many .NET developers. Paket provides a better experience for them. If your other issues (platform support, etc) aren't handled, people won't find it a better experience, and won't use it.

Our data currently shows that NuGet.org is accessed by 10s of different kinds of clients, if not more (hard to know for sure, since we don't have a contract for the client to share a well know name and version :( ).

I would recommend that be included in your API in the future, since you're talking about changing it anyways. However, it's tough to force even if it's there.

What is the objective criteria we can use here to triage requests?

There are many things you could use. I'll give some ideas, with Paket as an example of how proof could be supplied:

Usage counts: Can you document that a not-insignificant number of projects rely on this? For example, going back to Paket, it's easy to show thousands of open source projects use it today [which doesn't include commercial/private users, etc].
History of support: Can you show that the project is actively maintained, improved, etc? Easy if it's open source - just look at contributions/contirbutor counts/release history/etc
Traffic: Tough now, but if you included in API, this could easily work into criteria

We will almost certainly need to do additional more UX work to give the user more information so they can make an informed choice about who supports the client, what scenarios work, what don't, and so on.

As far as I can tell, nuget.org doesn't include anything related to the dotnet cli client. Really, documentation is just pushed off to Microsoft docs sites. I don't see why other clients should be different in this regard.
If you add UX work around this, including that any candidate to be included also add themselves in that documentation seems reasonable.

@unniravindranathan
I am sorry but I still do not understand the issue here. the PR was for adding a single tab for a single client Paket. I don't know how many other clients have a similar pr, but I still fail to see how that affected the Paket PR. if it get to a point that there are too many tabs simply say that a ux redesign is needed before any more tabs can be added.
As for your first point my thoughts are as follows.
I choose what is core to my experience as a .net developer and I don't like people dictating to me what it should be. that being said I understand that nuget.org can have there own standards, but I fail to see how that effects third party clients. why should the nuget team care at all what client I decide to use. Its the same for support why anyone would expect nuget to support a third party client doesn't make sense and is solved by adding a disclaimer that the nuget team isn't responsible for third party clients.
I guess what is most confusing to me right now is why even OSS the nuget.org site.  what were the goals of doing that if this type of PR is going to cause such an issue? maybe if that goal was made clear things would make more sense.
all that being said I really appreciate you thinking out loud.

There is no reason for this to be an issue. Consider this alternative. Give every third party client who asks for it a tab, but nobody sees them without taking a specific action. Create two URLs for every client (including the official Microsoft ones), something like nuget.org/paket/add and nuget.org/paket/remove. If I visit the add URL, then I see the tab for Paket, until I visit the remove URL Leave it to the third party clients to direct people to their add URL.
If I visit nuget.org without having visited any of the add/remove URLs (or having removed all the tabs), then show me the Microsoft clients' tabs.

Maybe add to Reed's list:

Presence of unique features (which make the client uniquely useful in special use cases)

@cdrnet I had left that out because feature worth seems very subjective... somethi ng important to a group of users may seem trivial to others. I figured usage covers that; if a client doesn't provide unique features, I don't see how they'd grow a user base, especially given that nuget is "in the box" ( in vs, dotnet tooling, etc)

I find it amusing that attempts at blocking additional package managers is so easily overridden by means of a trivial browser extension like paket-attacket. For what it's worth, the new NuGet Gallery, while it looks nice, is still only useful as a means of looking up versions and their related dependencies. I don't know anyone who uses the NuGet Gallery to figure out how to install a package. However, I could see that being useful to newer employees doing it for the first time, and they are not going to care about any one-sided decisions you may have made if their employer uses paket or another third-party client. They will just be left confused and unable to use your site or worse, get themselves in some trouble for using the wrong tool.
The most worthwhile point I've seen hasn't come from the Microsoft team but by commentors: adding additional clients could eventually become a problem due to space constraints. I would assume that would be a good problem to have. I personally have no idea why anyone would care about whose client is used. They are just tools. The best news is that everyone is happy with the NuGet package system. I remember the package manager confusion several years ago (as well as how Microsoft poorly handled that situation with the community). This is definitely not that. You actually have community members trying to work with you.

Our data currently shows that NuGet.org is accessed by 10s of different kinds of clients, if not more ... What is the objective criteria we can use here to triage requests?

I think the simple criterion here is ... has any other third-party client made such a request? Because, really, I highly doubt that you'll be getting requests from every Tom, Dick and Harry NuGet client to appear on the website. It takes a lot of effort for a package manager to get to the point that people feel comfortable with asking MS to even mention it ... and Paket has somehow reached that point. IMO, that effort shouldn't be squashed with a ton of 'what if' scenarios.

In the interest of defining criteria for listing clients on NuGet.org’s package details page.
There are GitHub stars. Getting more than a handful of stars is no small feat hard. Pick a number, any number.
Libraries.io has a metric called "SourceRank." Paket's current score is 12. Nuget.Client's score is 15, and for perspective, NPM's score is 25.
And I'm sure there are plenty of other sites that score open source projects, and provide a quick glance into a project's health.
It seems like the primary concern should be project health today and into the future. The SourceRank break down makes it easy to see where a project may have weaknesses that need addressed. In the event the NuGet team wanted to push back on a particular client, the team could provide specific goals for said client to overcome. For example: "Your NuGet client currently has only one contributor listed on GitHub. Please increase project involvement, and check in with us again in a few months."
(Aside, Paket is clearly one of those successful projects that wouldn't be questioned based on criteria like this. But the above is something that could give the NuGet team permission to let some in and provide grounds to dismiss others until their project grows to a sufficient size.)

Let's be honest, space is not an issue today. It will be an issue when there are a sufficient number of clients, but how that is handled is not a problem that needs solved today. For the moment there is plenty of space. Plus the visuals should primarily be the problem of your resident designer (not some committee of coders). Please shelve that reason to hold the horses.

I do think providing a link to a little more information about each client is worthwhile. That information should include a brief description and a link to the client's project page, and could include a "NuGet does not support, endorse, etc." disclaimer as applicable. That information could be a page hosted on NuGet.org, a little popover, or a modal (I noticed you are using Bootstrap, easy). Here's a screenshot of a new Paket tab with a little question mark that would open the page/popover/modal. This little question mark and corresponding information seems like it would even benefit the first party clients. Not everyone know what the Package Manager Console is or how to get to it in VS.

This issue is premature optimization.

Hi @unniravindranathan, a lot of good ideas and comments were added to this thread since you last commented on the issue. Could you please give us an update on the current position of the NuGet team on what (if any) should the criteria be for listing clients on NuGet.org’s package details page?

First of all, thanks to everyone who participated in this discussion. Here is update from the NuGet team:
We believe that having multiple clients listed on the package details page will have a positive impact on the .NET eco-system. However, we also want to ensure the promoted clients match our customer’s expectation, which includes being secure & being actively maintained. We also want to avoid a situation where we the list of clients is becoming unwieldy. Hence, we believe that it is important that we agree on the set of criteria for listing clients on NuGet.org.
Now that we are done with the major releases from the week before, we took the feedback on this thread, as well as our own, and distilled it down into a proposal that I would like to discuss with you:
We will list clients on NuGet.org that meet the following criteria:

Significant adoption in .NET community: The client should have significant adoption within the .NET community. This can be proven in a number of ways, such as:

Demonstrated usage of the client in a large number of .NET projects.
Client usage for downloading top packages from NuGet.org. As an example, see the set of clients downloading Newtonsoft.Json

Actively maintained and updated: The client should be actively maintained and regularly updated to respond to NuGet's changing protocols and users' feedback. This can be proven in a numbers of ways, such as

Frequent GitHub contributions
Frequency of client updates published to common download endpoints such as NuGet.org or the Visual Studio Gallery

Security compliance: The client should be compliant with the latest security requirements as implemented by NuGet.org. The NuGet.org team will publish these requirements, as well as the roadmap required for compliance. Later this week, we will articulate the mechanism we will be using for communicating these requirements.

Once listed, a client will be notified if it fails to satisfy one or more of the criteria mentioned above. Non-compliance with the notification will result in the client being removed from the listing.

The following is proposed experience for the listing:

A client will be shown as a separate tab on NuGet.org package details page as shown below:

We will add a hyperlink in the info message that can guide users to the respective tool's support page. For package consumers, the link can help to go to the right place to get more information, support and report issues. For the tool owners/maintainers this will ensure that their customers have a way to reach out to them and thereby creates additional channel to get feedback.
If there ends up being more clients than fits in the real-estate available, we will revisit the design for the listing at that point in time.

Based on the above criteria, we feel that we are ready to add Paket once the appropriate metadata has been added to the PR and the UI work has been completed. We will soon be starting work on making the UI changes above as tracked by https://github.com/NuGet/NuGetGallery/issues/4589.

In general, if your tool meets the criteria as listed above, please create a new issue to add your tool to the package details page with the relevant information as called out above. Alternatively, if you want to discuss specific details about your client, please feel free to send me an email.

This is a good step forward, and looks good to see. Once the UI changes are completed, can you add a comment or something to #4437 so it's clear what changes need to be made?
Thanks!

I have a few questions about this part:

Security compliance: The client should be compliant with the latest security requirements as implemented by NuGet.org. The NuGet.org team will publish these requirements, as well as the roadmap required for compliance. Later this week, we will articulate the mechanism we will be using for communicating these requirements.

Will the NuGet community have input into these security requirements? If not, why not?
Will the motivation and reasoning behind the requirements be communicated (in addition to the requirements themselves)?

Update: The required changes to enable third-party tabs is done now. Hence I am closing this issue. I will also be commenting on the original PR:https://github.com/NuGet/NuGetGallery/pull/4437 request so that new changes can be done and merged to enable Paket tab.
Please refer to the associated PR on the issue: https://github.com/NuGet/NuGetGallery/issues/4589 to understand the changes required to enable third-party clients.


Store Ids in Lowercase

Github doesn't transform Path Params to lowercase, so it seems like not being a good practise


Alignment in arrangements is may have unnecessary restrictions

See this thread in the forum:
https://groups.google.com/forum/#!category-topic/mitappinventortest/JthYE6ZdxWU
Note that the problem is fixed by changing the HorizontalArrangement  to give is a fixed height and making the VerticalAlignment centered.  But should that be necessary?
Also, in general, if you have a horizontal arrangement whose height is Automatic, then you cannot change the vertical alignment.  (similarly for width/Horizontal).   Hal put this restriction in, but he doesn't remember why, or whether it is necessary.

The possible explanation i can find is that this feature might be used for guiding user to set layout alignment. That can avoid a user wondering why there is no changes after setting AlignVertical to centre when layout height is Automatic.

Adding ghica's comment:
Try the attached .aia
The height of the 2 buttons will become not equal, if they have different amount of text lines in them, also in the test version given here.
The workaround now is: Go to the design view, set the height of the Horizontal Arrangement to something fixed, then set AlignVertical to center. Then you can set the height back to automatic if you wish. After this, the buttons will look OK.
But the real fix should be something more logical I think.
Cheers, Ghica.

Yucun,
Here is a picture.

It shows the screen after the top "try" button is pressed, and it shows that the buttons are not properly aligned.
I also uploaded a new, modified .aia, to make it (I hope) easier to see what is wrong.
Try the "try" buttons from top to bottom. The first one will show the problem.
The last one will set Align Vertical to center. And that fixes the problem.
You cannot do this from the design view, because "center" is greyed out.
One other remark, I do not know whether you can fix that too: The documentation does not tell how to set the AlignVertical attribute. It does not accept "center", therefore I tried 2 and it works.
Cheers, Ghica.
Met vriendelijke groeten,
Ghica van Emde Boas
email<EMAIL_ADDRESS>

adding Mark's comment:
So, it seems that there are some inconsistencies between App Inventor behavior and the documentation, as well as the UI inconsistency I pointed out earlier.
The AI documentation for the HorizontalArrangement (see here) states that the AlignVertical property has no effect if the arrangement's height is automatic.  Ghica's app shows that this is not the case.  Changing the AlignVertical property of a HorizontalArrangement does have an effect!  I suggest either trying to understand the effect, documenting it properly and allowing the designer to change the property or, if the desire really is to have property change have no effect then there's a bug that needs to be fixed.  There may be a similar bug with respect to the AlignHorizontal property when the arrangement's width is automatic but I haven't tested that.
A similar situation to the above probably exists for the VerticalArrangement component, which has similar documentation and UI designer behavior.
I'll also point out that there is another pretty bad inconsistency in the different ways that the UI designer and the device/emulator display buttons with long text.  It would be nice to fix the designer's rendering to at least come a little closer to the device (i.e. be able to do multi-line).
Ghica, please note that the AI documentation for the HorizontalArrangement does, in fact, specify that vertical alignment has the value 2.

See also #468 and check whether fixing that helps this issue.

Hi @halatmit
As Mark said, this unnecessary restrictions is different from issue #468. I have made a App Inventor instance for fixing this issue, in which the align editor is remove if height or width is automatic. If this looks fine, I can make a pull request for solving this issue.
The link for this issue: http://spinner-issue.appspot.com/

I'm not sure this is correct.   Here's an example with the system you just
put out.
It's a horizontal arrangement whose height is automatic.   Inside that is a
button with height 150 and a button with height 75.   It looks good.
[image: Inline image 1]
Now suppose I want to change this so that the two buttons are aligned at
the top (while the button texts are vertically centered withing each
button, as they are now).     To make that change I would expect to do that
by setting the alignVertical property of the Horizontal arrangement to
Top.  But that's not what happens in the current system (where that
property already is Top).   And I can't set that property at all in your
new system.
I agree that yours is better than the current system (which seems just
wrong).   But can it be fixed so that alignVertical does what I'm
expecting, both on the phone and in the designer?
== Hal Abelson
<EMAIL_ADDRESS>Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
MIT Media Lab, Second Class Faculty
On Sun, Jul 19, 2015 at 2:31 PM, liyucun<EMAIL_ADDRESS>wrote:

Hi @halatmit https://github.com/halatmit
As Mark said, this unnecessary restrictions is different from issue #468
https://github.com/mit-cml/appinventor-sources/issues/468. I have made
a App Inventor instance for fixing this issue, in which the align editor is
remove if height or width is automatic. If this looks fine, I can make a
pull request for solving this issue.
The link for this issue: http://spinner-issue.appspot.com/
—
Reply to this email directly or view it on GitHub
https://github.com/mit-cml/appinventor-sources/issues/410#issuecomment-122691669
.

Hi @halatmit
This scenario is related to issue #468. The button with 75 height is in centre of horizontal arrangement, it is because arrangement's baselineAligned attr is True by default so that two button have to be aligned based on their text.

As this pic shows, two buttons are aligned based on that red line (baseline).
If we set baselineAligned attr to False, it will looks like this:

This is what buttons should look like if we set Horizontal Arrangement alignVertical property to Top. And yes, Horizontal Arrangement alignVertical property is Top by default.
At this point, I have to change my mind to say: we should not restrict alignVertical property, it will make sense for user to set Top, Centre or Bottom.
Here is my new App Inventor instance: http://spinner-issue.appspot.com/
AI companion can be obtained by this link:
https://drive.google.com/open?id=0B82XjlreSEX_TzNPdFc0cGN5ZW8
There are still have some inconsistency between Designer view and phone view, but if you set AlignVertical to Top, Center, Bottom, it will show the right view on phone.

What I want is what's in the bottom of your two pictures in the case where
the Horizontal Arrangement alignVertical property is set to Top.
What I also want is that the two buttons should be center aligned when the
Horizontal Arrangement alignVertical property is set to Center.
And similarly, the bottomw of the buttons should line up when the
Horizontal Arrangement alignVertical property is set to bottom.
I understand that it would be only in the Center case that the text of the
two buttons would line up
Is that what you have?
== Hal Abelson
<EMAIL_ADDRESS>Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
MIT Media Lab, Second Class Faculty
On Sun, Jul 19, 2015 at 4:48 PM, liyucun<EMAIL_ADDRESS>wrote:

Hi @halatmit https://github.com/halatmit
This scenario is related to issue #468
https://github.com/mit-cml/appinventor-sources/issues/468. The button
with 75 height is in centre of horizontal arrangement, it is because
arrangement's baselineAligned attr is True by default so that two button
have to be aligned based on their text.
[image: image]
https://cloud.githubusercontent.com/assets/4750970/8767504/ffe0c9fa-2e2c-11e5-85ae-8d35c5881b5b.png
As this pic shows, two buttons are aligned based on that red line
(baseline).
If we set baselineAligned attr to False, it will looks like this:
[image: image]
https://cloud.githubusercontent.com/assets/4750970/8767510/379808ea-2e2d-11e5-96bb-3ea173ae6386.png
This is what buttons should look like if we set Horizontal Arrangement
alignVertical property to Top. And yes, Horizontal Arrangement
alignVertical property is Top by default.
At this point, I have to change my mind to say: we should not restrict
alignVertical property, it will make sense for user to set Top, Centre or
Bottom.
Here is my new App Inventor instance: http://spinner-issue.appspot.com/
AI companion can be obtained by this link:
https://drive.google.com/open?id=0B82XjlreSEX_TzNPdFc0cGN5ZW8
There are still have some inconsistency between Designer view and phone
view, but if you set AlignVertical to Top, Center, Bottom, it will show the
right view on phone.
—
Reply to this email directly or view it on GitHub
https://github.com/mit-cml/appinventor-sources/issues/410#issuecomment-122706392
.

Hi @halatmit
Yes, this instance covers all these three cases you described.

@liyucun
Please submit a pull request for this, so we can experiment with it and do a review.  Thanks.

#474 was closed


Unable to create the SharePoint list using Powershell

Hello Team,
I was trying to create the SharePoint lists via Powershell in order to deploy the Incentives app. I followed the instructions from the deployment guide but received the below error.
Could you check what went wrong here and if we have to do anything extra apart from the deployment guide?

Please advise.

We were not able to repro this issue.
Please let us know if issue is not resolved yet.


Add saved phrase

The separation of preset and saved Phrases necessitates us to re-model and store saved phrases. Keep in mind, there is some existing code for this already, but don't be afraid to re-implement.
As a user, I want to be able to add a new phrase to a category.
Scenario 1 - Home screen
Given: I am viewing a category
When: I select "Add Phrase"
And: Save the new phrase
Then: I should see the new phrase within that category
Scenario 2 - Settings
Given: I am viewing a category
When: I select "Add Phrase"
And: Save the new phrase
Then: I should see the new phrase within that category

This appears to be largely implemented, except there's one remaining issue: if you add a phrase on the home screen, you need to change categories to see it appear.

This should be implemented now. The only remaining thing is to remove the editCategories property from EditCategoriesViewModel, as it is no longer needed.


expense upload is failing

expenses can't be uploaded, this can be reproduced in production.

This just got me too. Since it's not possible to create an expense without an attachment, I'm completely stuck right now.

Thanks @aaronpk for bumping this up. we'll be fixing it soon.

@aaronpk this is fixed now.
best


[WIP] flux: add compatibility for Flux in the ATS codebase

Per our discussion today this PR is opened to test the compatibility of a work-in-progress Flux executor and monitor the progress of expanding ATS compatibility for Flux.
Currently, the Flux executor has option compatibility for:

number of cores
number of nodes
exclusivity within an allocation
verbose output of Flux key value store

To test this on Ruby (or another slurm-runnning LC cluster), install ATS in a virtual environment and request an allocation from slurm:
salloc -N 3 -p pdebug -A cbronze -t 60
And then start a flux instance using srun:
srun -N 3 --pty flux start

I'm setting the base branch as python3 to isolate the changes that I made. When I have the okay from @dawson6 I'll work out the kinks between my branch and main.

Thanks, @jameshcorbett, and sorry for the delay in pushing this -- still finding my way around in git. I think I addressed all of your comments (hopefully more to come ;))

If you wanted to, you could then read the jobspec that Flux constructed, and verify that the numbers check out.

Upon further thought I think that's a good idea but I would actually use Flux's jobspec class to read in the jobspec that was constructed. And I had forgotten that you won't be able to import the FluxScheduled class unless you have the flux package, so the check of whether Flux is installed is somewhat redundant.

Well groan. I'm sure I did something wrong to make the working tree this out of whack, but this should be aligned with the main branch.
Making a note to myself that this is what I did and in the future I should not do this again (it seems like rebase should do this better but I must be using it wrong)
(fluke_ats) [hobbs17@corona173:ATS]$ git config pull.rebase true
(fluke_ats) [hobbs17@corona173:ATS]$ git pull -X theirs upstream main

Tomorrow I'll go through machines.py and the commit history and make sure none of the commits from @dawson6 and @davidbloss change any of my implementation for Flux (but at first glance they shouldn't). And find a way to make my branch's commit history...less yucky.

All right, I believe I fixed the commit so that it will not have merge conflicts and can be merged into main once WIP is dropped. Making a note here that these are the pending actions for dropping WIP:

test GPU functionality again and make sure GPU allocation logic works for more complex cases
finish atsflux binding with additional functionality

I believe at this point I have addressed all of the must-haves for ATS/Flux but will run more tests on Monday to be sure.

I removed work-in-progress because I believe we are good for final review here. Thanks @dawson6, @jameshcorbett, and @davidbloss -- I believe I have addressed all of your comments from here and our meetings.


Save any changes to DST format

Why dst? They waste 512 bytes. They don't store colors. They aren't open source. Surely something like explicitly colored polyline svgs (the kind Embroidery offer can open might be more versatile.)

With the most recent commit I added the ability to save to DST (still has a color change bug), EXP, PEC and PES. Like you mentioned in another issue it would be nice to have for support for a phone plugged in via USB to the embroidery machine.


Come up with project structure and different name

Reason/Context
At the moment the project joined asyncapi organization so there is no need to have java-asyncapi name for the repo for 2 reasons:

asyncapi is a duplicate here
current name is way to generic

Another thing is, that this repo does not only contain the core of the project but also configurations and code for intelij, maven and gradle plugins.
Description
Please try answering few of those questions

I have no idea at the moment what would be the best name. I hope that creator or current community can suggest something. Maybe we should indicate in the repo name that it is code-first? but it is not that good, especially that it now has java in the name that also is not the best indicator as it is also possible to use project in Kotlin. So as you can see, it is a challange 😄
I think it can be a monorepo and plugins be part of it, no need to split to separate repos imho. Also the name of the repo/project should not be affected by the fact that plugins are here too

@jhigginbotham suggested in our Slack name jasyncapi => jay-sync-api
I like it, @fmvilas and @Pakisan too. Nobody objected or proposed anything different so I say let's go.
Rename of the repo is easy, GitHub keeps redirects. So @Pakisan the redirect for IntelliJ to authorize the plugin will still work well. What else do we need to do to rename the packages?

@jhigginbotham suggested in our Slack name jasyncapi => jay-sync-api
I like it, @fmvilas and @Pakisan too. Nobody objected or proposed anything different so I say let's go.
Rename of the repo is easy, GitHub keeps redirects. So @Pakisan the redirect for IntelliJ to authorize the plugin will still work well. What else do we need to do to rename the packages?

@derberg we can rename it without any problems. But we can't rename package from com.asyncapi to com.jasyncapi because of domain ownership validation. Right now jasyncapi.com didn't belongs to us. So it's unreal to do right now.
Anyway it's really strange thing for me to move out this project under new domain only because of renaming

@derberg we can rename it without any problems. But we can't rename package from com.asyncapi to com.jasyncapi because of domain ownership validation. Right now jasyncapi.com didn't belongs to us. So it's unreal to do right now.
Anyway it's really strange thing for me to move out this project under new domain only because of renaming

no no, com.asyncapi should definitely stay, no question about it

no no, com.asyncapi should definitely stay, no question about it

any objections, especially technical ones, or can I rename repo now

any objections, especially technical ones, or can I rename repo now

@derberg

any objections, especially technical ones, or can I rename repo now

I don't see any hidden problems for now. Let's rename repo

@derberg

any objections, especially technical ones, or can I rename repo now

I don't see any hidden problems for now. Let's rename repo

@Pakisan done 💪🏼
next?

@Pakisan done 💪🏼
next?

I think that is enough for now

I think that is enough for now

shouldn't this https://mvnrepository.com/artifact/com.asyncapi/asyncapi be https://mvnrepository.com/artifact/com.asyncapi/jasyncapi ? and the same in other places?

@derberg Will rename at next release

@Pakisan this one is not done yet, right?

@derberg
Yes, your a right. Idea's plugin was already moved out. After extraction of maven/gradle plugin we are done.

Isn't this issue already solved?

Isn't this issue already solved?

No, last question left - rename artifacts or not
https://github.com/asyncapi/jasyncapi/issues/11#issuecomment-770675741

@Pakisan hey man, how are you? can you confirm situation with artifacts?


Fix zero'd gradients from save_start

Needs https://github.com/JuliaDiffEq/DiffEqBase.jl/pull/200/commits/bc3efaa898832a14f554e3c542f73233edab8174


Add doc for generated methods for missing-docs option

Without these docs, the project use it may trigger this error when run clippy with -D missing-docs:
error: missing documentation for a function
  --> rpc/src/module/chain.rs:56:1
   |
56 | #[rpc(openrpc)]
   | ^^^^^^^^^^^^^^^
   |
   = note: requested on the command line with `-D missing-docs`
   = note: this error originates in the attribute macro `rpc` (in Nightly builds, run with -Z macro-backtrace for more info)

error: could not compile `ckb-rpc` (lib) due to previous error

bors merge


Show visual-oriented 3D node gizmos only when selected

Affected nodes:

DirectionalLight3D, OmniLight3D, SpotLight3D
ReflectionProbe
LightmapGI
VoxelGI
GPUParticles3D (but not collision/attractor nodes)
AudioStreamPlayer3D

This reduces visual clutter in the editor with 3D scenes.
Note that when selecting multiple nodes, none of them is considered as selected for gizmo drawing. This is not a new issue, but it'll become more noticeable with this PR.
Use https://github.com/godotengine/godot/pull/75303/files?w=1 to review changes (ignore whitespace changes).

See https://github.com/godotengine/godot-proposals/issues/6564.

Before

After

@wickedinsignia By the way, I wonder if this should apply to the Decal node gizmo as well. Being a purely visual element, it might get in the way if you have a lot of static decals placed in your scene.

@WickedInsignia By the way, I wonder if this should apply to the Decal node gizmo as well.

Haven't used the Decal node myself before but just gave it a play-around, and that could be optimal. The gizmo doesn't seem to be selectable and you need to use the Scene Outliner to select decals anyway, so there's no real loss in function if that's hidden.
It seems that Unity keeps the bounding box for these visible at all times though.
It's not too big a deal that we keep these visible if there's an easily accessible "gizmo" toggle that turns all gizmos in the scene on/off. Maybe that functionality already exists but I haven't found it, and this would be extremely useful if placed in the 3D editor toolbar.
Not sure I can be the one to decide the best choice around the decal node considering how little I've used it though.

It's not too big a deal that we keep these visible if there's an easily accessible "gizmo" toggle that turns all gizmos in the scene on/off. Maybe that functionality already exists but I haven't found it, and this would be extremely useful if placed in the 3D editor toolbar.

This is already available with View Gizmos in the Perspective menu, but it should be exposed with a more visible button (and a shortcut) indeed. This is a per-viewport setting, so I guess it'd need a button located on the left of the Perspective menu.

Thanks! I've decided to merge this despite the latest review comments because technically this PR didn't touch those lines, only changed the indentation. It would be good to have a consistency, but this is very minor.

Is there any way to be able to see where the probes are placed now?

Any chance this will be cherry-picked for 4.1.x?

4.2 will be released in less than a month, if you want usability enhancements such as this one, I suggest testing the betas.

@WickedInsignia By the way, I wonder if this should apply to the Decal node gizmo as well.

After playing around with the Decal node some more I believe it would be best if the bounds are hidden when the node is not selected. The bounds become a mess of wires fairly quickly and I can't identify much use in referencing the bounds when deselected. It appears Unity and Unreal hide them when deselected as well.


PS4 build fix

PS4 headers doesn't define __cpp_lib_launder which fails to compile with -Werror
Thanks for the nice library

Ahaa PS4 is really a pain for modern C++! 😄
Afaik, the last update of the toolchain should work. On the other side, I don't see any issue with the change. So... 🤷♂

I can't try this on PS4 at the moment though.
Can you confirm that you tested it and it works as expected also on the target platform?

I don't have physical access to ps4 to run the unit tests.  I'm getting our build machine to pass
If it helps boost is doing something similar here

Ahah well, yeah, it's quite reassuring actually. 🙂 Thanks for the PR.


HBASE-23369 Auto-close 'unknown' Regions reported as OPEN on RegionSe…

…rvers
Master force-closes unknown/incorrect Regions OPEN on RS
Also tunes the HBCKSCP procedure so it is more selective
come assign-time recovering an 'Unknown Server'
M hbase-client/src/main/java/org/apache/hadoop/hbase/MetaTableAccessor.java
Added a note and small refactor.
M hbase-server/src/main/java/org/apache/hadoop/hbase/master/CatalogJanitor.java
Fix an NPE when CJ ran.
M hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java
Minor clean up of log message; make it clearer.
M hbase-server/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java
Make it so closeRegionSilentlyAndWait can be used w/o timeout.
M hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/AssignmentManager.java
If a RegionServer Report notes a Region is OPEN and the Master does not
know of said Region, close it (We used to crash out the RegionServer)
M hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/RegionStateNode.java
Minor tweak of toString -- label should be state, not rit (confusing).
M hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/RegionStates.java
Doc.
M hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/TransitRegionStateProcedure.java
Add region name to exception.
M hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/HBCKServerCrashProcedure.java
Be more careful about which Regions we queue up for reassign. This
procedure is run by the operator so could happen at any time. We
will likely be running this when Master has some accounting of
cluster members so check its answers for what Regions were on
server before running.
M hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java
Doc and we were misrepresenting the case where a Region as not in RIT
when we got CLOSE -- we were reporting it as though it was already
trying to CLOSE.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 17s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2.2 Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 35s
branch-2.2 passed

+1 :green_heart:
compile
1m 27s
branch-2.2 passed

+1 :green_heart:
checkstyle
2m 10s
branch-2.2 passed

+1 :green_heart:
shadedjars
4m 26s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 58s
branch-2.2 passed

+0 :ok:
spotbugs
3m 36s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
4m 50s
branch-2.2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 15s
the patch passed

+1 :green_heart:
compile
1m 22s
the patch passed

+1 :green_heart:
javac
1m 22s
the patch passed

-1 :x:
checkstyle
1m 29s
hbase-server: The patch generated 1 new + 220 unchanged - 0 fixed = 221 total (was 220)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedjars
4m 26s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
hadoopcheck
16m 34s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1 :green_heart:
javadoc
0m 56s
the patch passed

-1 :x:
findbugs
3m 35s
hbase-server generated 1 new + 0 unchanged - 0 fixed = 1 total (was 0)

_ Other Tests _

+1 :green_heart:
unit
3m 21s
hbase-client in the patch passed.

+1 :green_heart:
unit
221m 50s
hbase-server in the patch passed.

+1 :green_heart:
asflicense
0m 49s
The patch does not generate ASF License warnings.

289m 42s

Reason
Tests

FindBugs
module:hbase-server

Dead store to risCount in org.apache.hadoop.hbase.master.procedure.HBCKServerCrashProcedure.getRegionsOnCrashedServer(MasterProcedureEnv)  At HBCKServerCrashProcedure.java:org.apache.hadoop.hbase.master.procedure.HBCKServerCrashProcedure.getRegionsOnCrashedServer(MasterProcedureEnv)  At HBCKServerCrashProcedure.java:[line 77]

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/902

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 5ad3ca8db150 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-902/out/precommit/personality/provided.sh

git revision
branch-2.2 / 44614438d2

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/1/artifact/out/diff-checkstyle-hbase-server.txt

findbugs
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/1/artifact/out/new-findbugs-hbase-server.html

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/1/testReport/

Max. process+thread count
3862 (vs. ulimit of 10000)

modules
C: hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/1/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 16s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2.2 Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 35s
branch-2.2 passed

+1 :green_heart:
compile
1m 22s
branch-2.2 passed

+1 :green_heart:
checkstyle
2m  9s
branch-2.2 passed

+1 :green_heart:
shadedjars
4m 26s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 58s
branch-2.2 passed

+0 :ok:
spotbugs
3m 39s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
4m 53s
branch-2.2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 14s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 15s
the patch passed

+1 :green_heart:
compile
1m 28s
the patch passed

+1 :green_heart:
javac
1m 28s
the patch passed

-1 :x:
checkstyle
1m 31s
hbase-server: The patch generated 1 new + 220 unchanged - 0 fixed = 221 total (was 220)

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedjars
4m 26s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
hadoopcheck
16m 48s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1 :green_heart:
javadoc
1m  3s
the patch passed

+1 :green_heart:
findbugs
5m 26s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
3m 24s
hbase-client in the patch passed.

-1 :x:
unit
213m 54s
hbase-server in the patch failed.

+1 :green_heart:
asflicense
0m 48s
The patch does not generate ASF License warnings.

283m 20s

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/902

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux cd2b0a1ba86f 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-902/out/precommit/personality/provided.sh

git revision
branch-2.2 / 44614438d2

Default Java
1.8.0_181

checkstyle
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/2/artifact/out/diff-checkstyle-hbase-server.txt

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/2/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/2/testReport/

Max. process+thread count
3982 (vs. ulimit of 10000)

modules
C: hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/2/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Fix checkstyle. Test failure unrelated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 27s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2.2 Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
7m 19s
branch-2.2 passed

+1 :green_heart:
compile
1m 55s
branch-2.2 passed

+1 :green_heart:
checkstyle
2m 29s
branch-2.2 passed

+1 :green_heart:
shadedjars
5m 26s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m 17s
branch-2.2 passed

+0 :ok:
spotbugs
4m 22s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
5m 54s
branch-2.2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
7m  7s
the patch passed

+1 :green_heart:
compile
1m 46s
the patch passed

+1 :green_heart:
javac
1m 46s
the patch passed

+1 :green_heart:
checkstyle
2m 24s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedjars
5m 32s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
hadoopcheck
21m 47s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1 :green_heart:
javadoc
1m 19s
the patch passed

+1 :green_heart:
findbugs
6m 30s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
3m 27s
hbase-client in the patch passed.

-1 :x:
unit
222m 46s
hbase-server in the patch failed.

+1 :green_heart:
asflicense
0m 49s
The patch does not generate ASF License warnings.

308m 28s

Reason
Tests

Failed junit tests
hadoop.hbase.client.TestAsyncRegionAdminApi

hadoop.hbase.replication.TestReplicationSyncUpTool

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/902

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 4be0b6dfff13 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-902/out/precommit/personality/provided.sh

git revision
branch-2.2 / bd229d870e

Default Java
1.8.0_181

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/3/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/3/testReport/

Max. process+thread count
5101 (vs. ulimit of 10000)

modules
C: hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/3/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 15s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2.2 Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 35s
branch-2.2 passed

+1 :green_heart:
compile
1m 21s
branch-2.2 passed

+1 :green_heart:
checkstyle
2m  6s
branch-2.2 passed

+1 :green_heart:
shadedjars
4m 25s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
0m 58s
branch-2.2 passed

+0 :ok:
spotbugs
3m 30s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
4m 44s
branch-2.2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 10s
the patch passed

+1 :green_heart:
compile
1m 23s
the patch passed

+1 :green_heart:
javac
1m 23s
the patch passed

+1 :green_heart:
checkstyle
2m  8s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedjars
4m 27s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
hadoopcheck
16m 26s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1 :green_heart:
javadoc
0m 58s
the patch passed

+1 :green_heart:
findbugs
4m 45s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
3m 25s
hbase-client in the patch passed.

-1 :x:
unit
269m 14s
hbase-server in the patch failed.

+1 :green_heart:
asflicense
1m  1s
The patch does not generate ASF License warnings.

336m 30s

Reason
Tests

Failed junit tests
hadoop.hbase.replication.regionserver.TestRegionReplicaReplicationEndpoint

hadoop.hbase.util.TestFromClientSide3WoUnsafe

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/4/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/902

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux c3bcac9eabdc 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-902/out/precommit/personality/provided.sh

git revision
branch-2.2 / 631b1762fc

Default Java
1.8.0_181

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/4/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/4/testReport/

Max. process+thread count
4168 (vs. ulimit of 10000)

modules
C: hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/4/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
1m 52s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  1s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2.2 Compile Tests _

+0 :ok:
mvndep
0m 18s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
6m 28s
branch-2.2 passed

+1 :green_heart:
compile
1m 25s
branch-2.2 passed

+1 :green_heart:
checkstyle
2m  7s
branch-2.2 passed

+1 :green_heart:
shadedjars
4m 28s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  0s
branch-2.2 passed

+0 :ok:
spotbugs
3m 30s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
4m 47s
branch-2.2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 13s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
5m 17s
the patch passed

+1 :green_heart:
compile
1m 22s
the patch passed

+1 :green_heart:
javac
1m 22s
the patch passed

+1 :green_heart:
checkstyle
2m  9s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedjars
4m 27s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
hadoopcheck
16m 39s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1 :green_heart:
javadoc
0m 56s
the patch passed

+1 :green_heart:
findbugs
4m 35s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
3m 24s
hbase-client in the patch passed.

-1 :x:
unit
222m 44s
hbase-server in the patch failed.

+1 :green_heart:
asflicense
0m 48s
The patch does not generate ASF License warnings.

291m 55s

Reason
Tests

Failed junit tests
hadoop.hbase.quotas.TestClusterScopeQuotaThrottle

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/5/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/902

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux a1c28502ef85 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-902/out/precommit/personality/provided.sh

git revision
branch-2.2 / 3223c50de7

Default Java
1.8.0_181

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/5/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/5/testReport/

Max. process+thread count
4290 (vs. ulimit of 10000)

modules
C: hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/5/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Updated comments in HBCKSCP after reading HBASE-23594. Otherwise, same.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 39s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2.2 Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m  4s
branch-2.2 passed

+1 :green_heart:
compile
1m 22s
branch-2.2 passed

+1 :green_heart:
checkstyle
2m  0s
branch-2.2 passed

+1 :green_heart:
shadedjars
4m  6s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  1s
branch-2.2 passed

+0 :ok:
spotbugs
3m 11s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
4m 21s
branch-2.2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 40s
the patch passed

+1 :green_heart:
compile
1m 20s
the patch passed

+1 :green_heart:
javac
1m 20s
the patch passed

+1 :green_heart:
checkstyle
1m 58s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedjars
4m  0s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
hadoopcheck
15m  5s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1 :green_heart:
javadoc
1m  1s
the patch passed

+1 :green_heart:
findbugs
4m 52s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
3m 35s
hbase-client in the patch passed.

+1 :green_heart:
unit
170m 24s
hbase-server in the patch passed.

+1 :green_heart:
asflicense
0m 55s
The patch does not generate ASF License warnings.

233m 35s

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/6/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/902

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux da73462506a9 4.15.0-60-generic #67-Ubuntu SMP Thu Aug 22 16:55:30 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-902/out/precommit/personality/provided.sh

git revision
branch-2.2 / a841bf15b0

Default Java
1.8.0_181

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/6/testReport/

Max. process+thread count
4858 (vs. ulimit of 10000)

modules
C: hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/6/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

@Apache9  Objections still? See JIRA for response to your previous problems with this patch.

Undid changes to HBCKSCP in here. They are just checking for deviation between ServerStateNode and RegionStateNode location. There should be none.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

+0 :ok:
reexec
0m 45s
Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s
No case conflicting files found.

+1 :green_heart:
hbaseanti
0m  0s
Patch does not have any anti-patterns.

+1 :green_heart:
@author
0m  0s
The patch does not contain any @author tags.

-0 :warning:
test4tests
0m  0s
The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch.

_ branch-2.2 Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for branch

+1 :green_heart:
mvninstall
5m 50s
branch-2.2 passed

+1 :green_heart:
compile
1m 25s
branch-2.2 passed

+1 :green_heart:
checkstyle
2m  2s
branch-2.2 passed

+1 :green_heart:
shadedjars
4m 16s
branch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
javadoc
1m  0s
branch-2.2 passed

+0 :ok:
spotbugs
3m 16s
Used deprecated FindBugs config; considering switching to SpotBugs.

+1 :green_heart:
findbugs
4m 25s
branch-2.2 passed

_ Patch Compile Tests _

+0 :ok:
mvndep
0m 15s
Maven dependency ordering for patch

+1 :green_heart:
mvninstall
4m 48s
the patch passed

+1 :green_heart:
compile
1m 20s
the patch passed

+1 :green_heart:
javac
1m 20s
the patch passed

+1 :green_heart:
checkstyle
1m 58s
the patch passed

+1 :green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

+1 :green_heart:
shadedjars
4m  7s
patch has no errors when building our shaded downstream artifacts.

+1 :green_heart:
hadoopcheck
14m 58s
Patch does not cause any errors with Hadoop 2.8.5 2.9.2 or 3.1.2.

+1 :green_heart:
javadoc
1m  0s
the patch passed

+1 :green_heart:
findbugs
4m 44s
the patch passed

_ Other Tests _

+1 :green_heart:
unit
3m 27s
hbase-client in the patch passed.

-1 :x:
unit
161m 48s
hbase-server in the patch failed.

+1 :green_heart:
asflicense
1m  3s
The patch does not generate ASF License warnings.

226m 18s

Reason
Tests

Failed junit tests
hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush

Subsystem
Report/Notes

Docker
Client=19.03.5 Server=19.03.5 base: https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/7/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hbase/pull/902

Optional Tests
dupname asflicense javac javadoc unit spotbugs findbugs shadedjars hadoopcheck hbaseanti checkstyle compile

uname
Linux 949794fb5ae5 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
/home/jenkins/jenkins-slave/workspace/HBase-PreCommit-GitHub-PR_PR-902/out/precommit/personality/provided.sh

git revision
branch-2.2 / 0a989eae4e

Default Java
1.8.0_181

unit
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/7/artifact/out/patch-unit-hbase-server.txt

Test Results
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/7/testReport/

Max. process+thread count
4657 (vs. ulimit of 10000)

modules
C: hbase-client hbase-server U: .

Console output
https://builds.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-902/7/console

versions
git=2.11.0 maven=2018-06-17T18:33:14Z) findbugs=3.1.11

Powered by
Apache Yetus 0.11.1 https://yetus.apache.org

This message was automatically generated.

Was going to push this unless objection @Apache9

Hand-merged to branch-2 and master. Closed this PR.

I'm getting a build failure after this merge, boss:
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project hbase-server: Compilation failure
[ERROR] /Users/ndimiduk/repos/apache/hbase/hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/AssignmentManager.java:[1108,59] cannot find symbol
[ERROR]   symbol:   method getClusterConnection()
[ERROR]   location: variable master of type org.apache.hadoop.hbase.master.MasterServices

Thanks. Fixing.


Error doing job: Task exception was never retrieved

This error originated from a custom integration.
Logger: homeassistant
Source: custom_components/apple_airplayer/media_player.py:110
Integration: Apple AirPlayer (documentation, issues)
First occurred: 12:43:03 PM (4 occurrences)
Last logged: 12:48:16 PM
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/apple_airplayer/media_player.py", line 110, in async_play_stream
r = await session.get(url)
File "/usr/local/lib/python3.9/site-packages/aiohttp/client.py", line 520, in _request
conn = await self._connector.connect(
File "/usr/local/lib/python3.9/site-packages/aiohttp/connector.py", line 535, in connect
proto = await self._create_connection(req, traces, timeout)
File "/usr/local/lib/python3.9/site-packages/aiohttp/connector.py", line 892, in _create_connection
_, proto = await self._create_direct_connection(req, traces, timeout)
File "/usr/local/lib/python3.9/site-packages/aiohttp/connector.py", line 991, in _create_direct_connection
assert port is not None
AssertionError

It's not a universal media_player, just as a TTS speaker only, so, It's not all URL format can be supported.


Transparancy on the impact of each answers

Seeing the impact a question has would help with answering if the questions are too vague.

This could influence people's answers towards their preconceptions of their values, which could undermine the purpose of the quiz. I think the 'Neutral / Unsure' button suffices for the scenario you are referring to


[CONTRIBUTING.md] Add section about merging ECS conventions

Fixes #329
Changes
Add new section to CONTRIBUTING.md with expectations when merging existing ECS conventions.
Merge requirement checklist

[ ] CONTRIBUTING.md guidelines followed.
[ ] CHANGELOG.md updated for non-trivial changes.
[ ] schema-next.yaml updated with changes to existing conventions.

Trying to summarize the work needed here from previous SIGs and private discussions I have had about this. These are the questions that the community wants to understand to move this forward:

How many conventions from ECS don't follow our existing guidelines? So that we understand to how many misaligned conventions we are committing. Alexandra Conrad is working on this.
What tools/capabilities does Elastic have today to migrate their users if we were to rename conventions?
What tools would it be feasible for Elastic to build?
Is it harder to migrate users in some situations? For example, does host.ip being a leaf node in ECS and us introducing host.ip.addresses causes more trouble than a simple rename?

cc @AlexanderWert @MikePaquette

Hey @mx-psi I have finished my investigation on possible naming conflicts. Please check it below.
TL;DR:

pluralisation, i.e. ECS has fields which are arrays but key is singular. As prominent examples of it - *.ip and *.mac for arrays of ip or mac addresses, ~40 examples found in ECS
*.bytes fields which would be changed to the *.size ~15 examples
*.packets fields, I think they might be a subject to change as with previous field  ~10 examples
@ character in name, there is only 1 such example (@timestamp), not sure if it against naming rules
array of nested objects: ECS contains fields (for example dns.answers) which are arrays containing objects. ECS defines fields of this nested objects. I'm not sure yet how this would go into Otel schema. From this data model can we say that for attribute of type map<string, any>, any could be such an object too?

Here is detailed list of Namespaces and possible conflicting fields in it:

Base: @timestamp
Client: client.bytes, client.packets
Container: container.disk.(write|read).bytes, container.image.hash.all (array of hashes), container.image.tag (array of image tags), container.network.(ingress|egress).bytes
Destination: destination.bytes, destination.packets
DNS: dns.resolved_ip (Array containing all IPs seen in answers.data)
Email: email.(bcc|cc|from|reply_to|to).address - The email addresses
Event: event.category, event.type - arrays
Host: host.disk.(write|read).bytes, host.ip (Host ip addresses), host.mac (Host MAC addresses, array of values), host.network.(ingress|egress).bytes, host.network.(ingress|egress).packets
Http: http.request.body.bytes, http.request.bytes (body + headers), http.response.body.bytes, http.response.bytes
Network: network.bytes, network.packets
Observer: observer.ip, observer.mac are arrays
Orchestrator: orchestrator.resource.annotation (The list of annotations added to the resource.), orchestrator.resource.ip, orchestrator.resource.label - these are all arrays
Process: process.thread.capabilities.effective (set of capabilities used by the kernel to perform permission checks for the thread), process.thread.capabilities.permitted - these are arrays and we have rule in metrics that namespaces shouldn't be pluralised, but I'm not sure about these cases
Related: related.hash, related.hosts, related.ip, related.user - all arrays with data gathered all over the event, I'm not sure if it will be moved to Otel but potential conflict. (A concrete example is IP addresses, which can be under host, observer, source, destination, client, server, and network.forwarded_ip. If you append all IPs to related.ip, you can then search for a given IP trivially, no matter where it appeared, by querying related.ip:<IP_ADDRESS>.)
Server: server.bytes, server.packets
Source: source.bytes, source.packets
Threat: threat.(group|software).alias, threat.tactic.(id|name|reference), threat.technique.(id|name|reference), threat.technique.subtechnique.(id|name|reference) - these are all arrays
User: user.id is defined not as array but a user might have more than 1 ID associated
Vulnerability: vulnerability.category is an array
x509 Certificate: x509.issuer.(common_name| country|locality|organization|organizational_unit|state_or_province), x509.subject.(common_name| country|locality|organization|organizational_unit|state_or_province) - these are all arrays

@ character in name, there is only 1 such example (@timestamp), not sure if it against naming rules

Can we possibly ignore this conflict, as we likely won't have a @timestamp field on semantic conventions (as that's part data structure of signals themselves, and doesn't need to be in semantic conventions)?

How many conventions from ECS don't follow our existing guidelines? So that we understand to how many misaligned conventions we are committing. Alexandra Conrad is working on this.

This one has been answered above. Please also note, this might be not full list of all possible conflicts, while adding new fields we might find other naming conflicts, but I think this list is comprehensive enough

Is it harder to migrate users in some situations? For example, does host.ip being a leaf node in ECS and us introducing host.ip.addresses causes more trouble than a simple rename?

Yes, changing name is already a breaking change, but changing structure - in this case going from simple leaf with value/array of values to complex node with additional data underneath will have really strong negative impact on ECS users and tooling. I would strongly advise against it. Please also check comments in this PR for additional context

I have changed the status of the issue to get more attention from other approvers

Anything missing here? Or is this good to merge?


Update the staging-augmenter download URL to point to microprofile-bu…

…ild-infra repository

fixed in #1


MediaType 'mixed' not working properly on android

Bug

Environment info
Android API 28, Android API 27
react-native info output:
React Native Environment Info:
System:
OS: macOS 10.15.3
CPU: (12) x64 Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz
Memory: 21.18 GB / 64.00 GB
Shell: 5.7.1 - /bin/zsh
Binaries:
Node: 10.18.1 - /usr/local/opt/node@10/bin/node
Yarn: 1.22.0 - /usr/local/bin/yarn
npm: 6.13.4 - /usr/local/opt/node@10/bin/npm
Watchman: 4.9.0 - /usr/local/bin/watchman
SDKs:
iOS SDK:
Platforms: iOS 13.4, DriverKit 19.0, macOS 10.15, tvOS 13.4, watchOS 6.2
IDEs:
Xcode: 11.4/11E146 - /usr/bin/xcodebuild
npmPackages:
react: 16.8.3 => 16.8.3
react-native: 0.59.9 => 0.59.9
npmGlobalPackages:
react-native-cli: 2.0.1
Library version: NEWEST
Steps To Reproduce

integrate Image picker
call ImagePicker.launchImageLibrary()
mediaType: 'mixed
Only showing photos instead of mixed content
...

Describe what you expected to happen:

Instead of showing just photos there has to be mixed content

I experience the same issue :(

I have the same issue.
But its only happening on select phones. My Oneplus A5000. Works fine on my Samsungs.
The mediaType: Video on its own works fine. Photo and Video option is OK but Mixed Media is not.
Any suggestioons from anyone?

I also have the same problem. Did anyone find the solution?

Still have the same problem

i studied this deeper and found that the code that is in this package dosen't work for all Android API versions.
libraryIntent.setType("image/* video/*");
I had to switch to https://github.com/ivpusic/react-native-image-crop-picker which had the updated way of doing it.

i have a huawei mate 10 pro and not work, How do we fix this to make it compatible with more phones?

Same problem over here using android 10, react-native 0.63.0 and react-native-image-picker ^2.3.3.
The modification showed by @hannojg fixed the issue for me but now I have this other issue: https://github.com/react-native-community/react-native-image-picker/issues/1427 😞

Still having the issue here, seems like some people have a solution and forks, can someone submit a PR? 🙏

@Johan-dutoit @ravirajn22 wondering if you could check this? videos / images are not being picked up in some phones

Mixed is not supported in 3.x.x (yet...) and 2.x.x is no longer supported.


Fix Github link for Dance repository

Simple fix in documentation.

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


Best practices when setting row height

Are there any suggestions on how to go about creating a rowHeightGetter function?

I am interetested in this as well.  This seems to be a similar discussion - https://github.com/facebook/fixed-data-table/issues/322 - but it doesn't have any answers yet.

Posting this here because it seems to be the most general issue surrounding custom row height.
Using  ideas from react-measure and a custom prop on the Table called flexibleRows, I got quite far creating a grid with completely variable rowHeight measured from the row's own contents.
The initial table looks great but I got stuck when I realised FDT is reusing elements/not rendering rows outside of the viewport/some other magic! - so to measure rows again when they have new contents I've either got to force an update when you scroll or measure every time the cell updates with componentDidUpdate - either way is really laggy.
Any advice on this would be really welcome, as it's a lot of work for nothing, even though in the end having to implement this feature is very avoidable and I'm probably going to skip having dynamic content in my tables.
Callback function for when a cell is measured
handleCellMeasure(rowIndex, dimensions) {
    let rowHeights = this.state.rowHeights;

    // Only store the largest cell height of a row
    if(typeof rowHeights[rowIndex] == 'undefined' || rowHeights[rowIndex] < dimensions.height) {
        rowHeights[rowIndex] = dimensions.height;

        this.setState({
            rowHeights: rowHeights
        });
    }
}

The rowHeightGetter
Any time the grid asks for a row height, check if we've stored it's measurements in state
rowHeightGetter(index) {
    let rowHeight = 37; // Set the default rowHeight

    if(this.props.flexibleRows) {
        let calculatedHeight = this.state.rowHeights[index]; // Retreive the rowHeight stored in state
        if(typeof calculatedHeight != 'undefined') {
            rowHeight = calculatedHeight + 16; // 8px padding
        }
    }

    return rowHeight;
}

render
Then in the render of my Grid I am pushing my custom props into FDT components and I wrap the contents cell in a Measuring component.
<Table ...>
    {React.Children.map(this.props.children, el => {
        if(flexibleRows) {
            clonedCell = React.createElement(MeasureCell, {
                onMeasure: this.handleCellMeasure.bind(this)
            }, clonedCell);
        }
        // Many more extensions on the column and the header
        return React.createElement(Column, {
            ...props, // Props to pass through to the real column (injecting the data, also - which is neat)
            cell: clonedCell,
            header: headerCell
        });
    })}
</Table>

MeasureCell
The measure cell is just a component that wraps the cell and measures the height of the element.
// Find the cell contents and measure it
const dimensions = this._node.querySelector('.public_fixedDataTableCell_cellContent').getBoundingClientRect();
if(dimensions.height > 0) {
    this.props.onMeasure(this.props.rowIndex, dimensions); // Run the callback function seen above
}


[FEATURE] Load Prompts from Langsmith Hub

Load Prompts from Langsmith Hub
Langsmith Hub is a popular platform to discover, share, and version control prompts. This is a proposal for integration of Flowise to that platform to allow users to take advantage of a large library of prompts.
The following image depicts a draft thought process, and we are seeking inputs/suggestions on this feature.

A similar thought process will be implemented for ChatPromptTemplate as well.

is this doable in JS, I know python we can do
from langchain import hub
obj = hub.pull("homanp/superagent")

Yes, I have a basic version that works locally.
See Gist

ah didnt know they have langchain/hub

Draft PR in place for early review/feedback: https://github.com/FlowiseAI/Flowise/pull/1175


Invalid permission checking when authorizationStatus is always on iOS

LocationManager.previousAuthorizationStatus value is not updated,
AllwaysAllow Permission Fixes the problem that permission check was not performed.

Thx :)


isset not functioning properly in asset manifest

Submit a feature request or bug report

[ x ] I've read the guidelines for Contributing to Roots Projects
[ ] This is a feature request
[ x ] This is a bug report
[ ] This request isn't a duplicate of an existing issue
[ x ] I've read the docs and NPM Debugging Guidelines post and followed them (if applicable)
[ x ] This is not a personal support request that should be posted on the Roots Discourse forums

What is the current behavior?
My site is not loading in the proper (asset revved, minified) file.
What is the expected or desired behavior?
My site should load in the properly asset revved file (in production)

Bug report

Please provide steps to reproduce, including full log output:
I discovered the issue was in vendor/roots/sage-lib/Assets on line 31:
public function get($asset)
    {
        return isset($this->manifest[$asset]) ? $this->manifest[$asset] : $asset;
    }

That isset call is not actually working. $this-manifest[$asset] is actually present, but for some reason isset is saying it's not.
I'm generating a proper assets.json file in my theme that sources several hashed files properly. The WordPress theme is not using this file, for some reason, and is defaulting to scripts/main.js
(for example).
Please describe your local environment:
WordPress version: 8.2
OS: X: Latest
NPM/Node version: 7+
Where did the bug happen? Development or remote servers?
Remote
Is there a related Discourse thread or were any utilized (please link them)?
NO

i already replied to the discourse thread you created https://discourse.roots.io/t/production-variable-sage-9-wp-env-gone/10473/2?u=benword

@retlehs
I already ran yarn run build:production. That's why I'm saying there is a bug with this feature, because it wasn't loading in my minified files.
Please re-read my bug report more carefully. I'm generating a proper manifest in webpack with asset revved files, but the WordPres theme is not sourcing them.

yeah, this isn't a bug. you can post more on discourse if you need further support

@andrewmartin I'm really not sure why that would fix your problem. isset() returns true if the array key is there. Doing if($this->manifest[$asset]) is the same thing, except if the array key is not there, a notice will be thrown.
I'm honestly not sure why that would work for you but the original code does not. But this isn't an issue for anyone else. I would ask what PHP version you're running, but I really doubt that has any bearing on this.

@kalenjohnson I'm familiar with what isset does, and it's confusing to me as well. I'm using PHP 7.1.6.

locking this as every message is notifying over 600 people... discourse is the place for back and forth.


Allowing empty commits

I see there is a PR to allow empty commits during the plan phase, but when I try it out, it says unknown flag: --allow-empty-commit. This is the command I ran:
mp plan -b $BRANCH_NAME --allow-empty-commit -m "Commit msg"

BTW I installed microplane from homebrew on my Intel Mac

Hi, that PR has not made it into a released version yet. You can try building the latest commit from source: go install github.com/Clever/microplane@master (requires Go v1.17+ installed)


Create Event Component for the Social Event Page

The Component should be able to accept all the properties and create the event card for the user
The Card should be generic which should also provide click functionality

Hey Harshith, I would love to work on this issue!
Can you please assign me?

Assigned, thanks for reaching out🥂

Thanks Harshith! 😄