Project-specific variables

Something like key-value pairs that are stuck to Operations would be useful.
This would allow for people with custom Workers to make decisions based on a projects' variables.
An example: Slack channel names

create new project called '2023-Q1-example.com'

do normal setup like users, tags, groups, etc
create project variables

slack_channel: example.com_campaign
slack_webhook: https://.........

Create new evidence
A Worker can now query an operation's slack_channel variable and post to that slack channel that evidence was created

Currently I'm using a dictionary in source to map operation slugs to slack-channel slugs. On every new operation, I'm going in to the source to  add a new entry and then rebuilding/publishing new docker images. I then pull the image on a docker swarm manager and redeploy the slack worker.
I was about to start the process of modifying my worker to be able to read in and build that dictionary from environment variables, when the idea of operation variables popped in to my head.

A few clarifying questions. Would you want global ones for the instance as well? If so, would you want project specific ones to override the global ones?
How would you want the worker to get access to this data?

Yes, that could be useful for setting base urls to external services, as an example.
Yes, I think that's sound default behavior for configuration variables
I don't have strong feelings about whether the variables are pushed to workers, or if workers have to fetch them with an API call.

It's probably cleaner to make them available to read rather than pushing the same variables over and over.

This is a good idea
Yes
Having the server pass global and project variables along with the evidence should help minimize overhead from requests and serialization.

This should be closed with the 2023.3 release


Bring the console transport into line with others

When the consoleJSON flag is set, it runs the logstash formatter instead of setting winston's json flag to true.

If this PR is acceptable, I suggest a "squash & merge" to clean up the commit history.

The intention here was to have console logging as the more readable color winston format to assist debugging when running locally, as console logging should be turned off in deployed environments anyway.
While the logstash format is great for logfiles and kibana, it is a bit terse for console

@HughePaul: When we deploy stuff we only log to standard output. i.e. In production we want logstash format logging to stdout.

I this case we should have an option to still allow the winston console formatting style and not apply the formatter

I've revisited this and it is fine as you originally did it. I've rebased and added a test to bring the coverage back up.


Translate to italian

Since there is no .gitignore file I didn't bother not to commit autogenerated files, as I saw that's how it's done here

Hi. The Italian translation by another contributor has already been merged in the dev branch, to be released in the next update (should be soon). I still thank you for this patch and your work on NewPipe.

Oh, ok, I didn't check and just went on adding italian by myself ;-)
Perfect app for my grandmother


HIP-19 Remove any existing vendors who have not kept to production timescales with a sufficient explanation

We are beginning to encounter a problem now where big promises were made by companies who seemingly do not have the professionalism to handle large scale technology production/distribution and everything that goes with it.
There needs to be 1) Rigid production estimates and timescales that can only be officially extended with a full explanation. 2) Consistent & regular communication. 3) The opportunity for open discussion on the challenges being faced by the community. If the official timescales are not being met without any explanation and none of the above are being done then there should be a vote as to whether their license to produce devices should be extended or removed.

You have not said who will support existing hotspots if a vendor is blocked from selling units.

You have not said who will support existing hotspots if a vendor is blocked from selling units.

Perhaps an open standard could be adopted so the firmware needs to meet certain core requirements? It's a good point, however I don't think vendors should be able to hold customers hostage with lack of ongoing support. It does not seem like a huge ask to me to require some minimal level of frank & honest communication from vendors.
Another option could be to implement some kind of vendor-specific onboarding penalty; if an approved vendor is found (by some other authority mechanism beyond the scope of this comment) to be in violation of whatever the reporting criteria / requirements are, their onboarding fee to produce new units could be raised. They might try to pass this cost on to the customer but I would like to believe price sensitivity and competitive market forces (in combination with the degraded levels of service quality) would sort that out.

Hi @Thedailygrind, is this actually a HIP edit or just a discussion topic? It's hard to tell since it appears to be forked from an older version of this repository. Would you be able to rebase to the latest master to help with readability?

You have not said who will support existing hotspots if a vendor is blocked from selling units.

Perhaps an open standard could be adopted so the firmware needs to meet certain core requirements [and can be serviced / supported by other third parties]?

The software already is essentially an open standard and for the most part can be user updated - however the process is perhaps a bit too involved for some people (and/or manufacturer hasn't documented the process). And there is little incentive for one manufacturer to take over the firmware support of another manufacturer without charge due to the costs involved. However the light gateway stuff in gateway-rs does improve this significantly.
We have actually already put some effort into this process here and already can support all Raspberry Pi based hotspots on our firmware (I have a RAK and Helium OG running it) and in the future on our dashboard too. It is relatively trivial to add new support for other hardware however the one blocker on our firmware is the need to have at least ~500mb of RAM and ~1ghz processor. This is much more powerful than most lights will be (however for reasons stated above this is less of an issue with lights). Having said that, we are already in discussions with balena to host an "openFleet" for helium users to manage their own updates using our open source repos and they seem open to the concept generally (and it would be free).
It would be great to see DeWi maintaining an open firmware update channel or something to that effect in the future, perhaps in partnership with someone like balena and using some DeWi grant funds to facilitate it. The main complexity is just ensuring hardware support for all the different processor platforms.
Additionally, in the short term perhaps DeWi could require either fully open source software (definitely a preference as Helium is open source as is lots of crypto space and fits into the whole decentralisation thing) but if there is severe pushback to this then it could be that the vendor has to maintain a private software repo, that DeWi has secure access to, that contains all of their source code and instructions for building and deploying it so in the event there are any issues these can be easily resolved. It would also have the benefit of allowing more through security audits for example, among other things.
I don't see any reason why people wouldn't want to have the software open source anyway - given the core helium stuff already is. Would also be great to see more open source hardware in this space as well as discussed in #94

What do you think would be the best / easiest way for sellers to keep consistent & clear communication with its customers. What method, how often etc - What is needed to support this?

You have not said who will support existing hotspots if a vendor is blocked from selling units.

Perhaps an open standard could be adopted so the firmware needs to meet certain core requirements [and can be serviced / supported by other third parties]?

The software already is essentially an open standard and for the most part can be user updated - however the process is perhaps a bit too involved for some people (and/or manufacturer hasn't documented the process). And there is little incentive for one manufacturer to take over the firmware support of another manufacturer without charge due to the costs involved. However the light gateway stuff in gateway-rs does improve this significantly.
We have actually already put some effort into this process here and already can support all Raspberry Pi based hotspots on our firmware (I have a RAK and Helium OG running it) and in the future on our dashboard too. It is relatively trivial to add new support for other hardware however the one blocker on our firmware is the need to have at least ~500mb of RAM and ~1ghz processor. This is much more powerful than most lights will be (however for reasons stated above this is less of an issue with lights). Having said that, we are already in discussions with balena to host an "openFleet" for helium users to manage their own updates using our open source repos and they seem open to the concept generally (and it would be free). Example here.
It would be great to see DeWi maintaining an open firmware update channel or something to that effect in the future, perhaps in partnership with someone like balena and using some DeWi grant funds to facilitate it. The main complexity is just ensuring hardware support for all the different processor platforms.
Additionally, in the short term perhaps DeWi could require either fully open source software (definitely a preference as Helium is open source as is lots of crypto space and fits into the whole decentralisation thing) but if there is severe pushback to this then it could be that the vendor has to maintain a private software repo, that DeWi has secure access to, that contains all of their source code and instructions for building and deploying it so in the event there are any issues these can be easily resolved. It would also have the benefit of allowing more thorough security audits for example, among other things.
I don't see any reason why people wouldn't want to have the software open source anyway - given the core helium stuff already is. Would also be great to see more open source hardware in this space as well as discussed in #94

Running Nebra‘s software on other devices would be a death penalty for them. I believe that the goal should be to go the other way around; running a stable software on unstable Nebra‘s.
On the other hand, removing vendors is a great idea.

whether this is a new HIP or extension, i think this is a necessary addition to help protect our community members from being hustled and taken advantage of. This is something that i even now have finally reached my P-off level. I have stuck up and supported alot of these vendors, and now I can't help but feel like i was hustled. There are alot of vendors coming online to take advantage of our community volume, and that needs to be managed. I do not like that we have come to this point. but at the same time, it is our responsibility as a community to Call out the "Bad Actors" whether its trying to game the network or remove the HIP-19 Vendor Approval Status. Clearly, these vendors are only focused on there own bottom line, and not the Growth of the network. I feel for the people that may have ONLY had a few bucks to purchase just 1 hotspot, and now they can't participate in The Peoples Network, bc of a "Bad Actor"Vendor not sticking to there word. Or Vendors FOCUSED only on the Big Purchase orders and NOT the small 1-2 order sizes. We should start to communicate about removing Vendor Status, and also, maybe even suggest to vendors, at splitting the supply chain management, to Orders of less than 50, order sizes 50-500 and then 500+ . Maybe even Vendors could communicate to figure out that for example, Vendor A, only does supply for order sizes less than 50. Vendor B only focuses on order sizes greater than 100. and such. These are my thoughts,  pertaining to this. Would love to hear feedback from others. Either, someone Needs to stick up for the small fish in our community trying to help and participate in The Peoples Network.

This one lost me at "Rigid production estimates and timescales " - Rigid Estimates are not possible

What do you think would be the best / easiest way for sellers to keep consistent & clear communication with its customers. What method, how often etc - What is needed to support this?

I don't really understand your question?

Running Nebra‘s software on other devices would be a death penalty for them. I believe that the goal should be to go the other way around; running a stable software on unstable Nebra‘s.
On the other hand, removing vendors is a great idea.

I'm very confident our software stack is superior to all other vendors. But then, I'm biased :-)

What do you think would be the best / easiest way for sellers to keep consistent & clear communication with its customers. What method, how often etc - What is needed to support this?

I don't really understand your question?

I believe they're asking what your personal expectations are regarding customer service & communication, as a CEO of a HIP-19 approved manufacturer. Basically a public statement of record on your internal standards & practices regarding engagement with the customer/end user.
But @Thedailygrind should correct me if my interpretation is off.

....or, perhaps more succinctly, I think they're asking for an acknowledgement of specific shortcomings and steps that can be taken to address them.

What do you think would be the best / easiest way for sellers to keep consistent & clear communication with its customers. What method, how often etc - What is needed to support this?

I don't really understand your question?

I don't think there's even a different way to ask this but @cvolkernick did a decent job.
If you don't understand such a basic question about customer service then it might be why there's an issue in the first place.

@jamiew @cvolkernick How do we push this forward? We are still experiencing the same issues as when this was originally suggested. The community needs to demand better business practices from all its Vendors to support the ultimate goal of Helium and at this time I see no other way how.

@Thedailygrind See related comment: https://github.com/helium/HIP/issues/270#issuecomment-926292953

What do you think would be the best / easiest way for sellers to keep consistent & clear communication with its customers. What method, how often etc - What is needed to support this?

I don't really understand your question?

I believe they're asking what your personal expectations are regarding customer service & communication, as a CEO of a HIP-19 approved manufacturer. Basically a public statement of record on your internal standards & practices regarding engagement with the customer/end user.
But @Thedailygrind should correct me if my interpretation is off.

We have been doing weekly blogs and email updates, as well as communication on Twitter/Facebook and technical support via support tickets. As well as bug reports via GitHub.
This seems pretty robust to me, and we are actively hiring new support people almost every other week to increase our capabilities in communication and support.
As I've said before though, we are always open to ideas if people think there is a better way we can communicate with customers.

What do you think would be the best / easiest way for sellers to keep consistent & clear communication with its customers. What method, how often etc - What is needed to support this?

I don't really understand your question?

I believe they're asking what your personal expectations are regarding customer service & communication, as a CEO of a HIP-19 approved manufacturer. Basically a public statement of record on your internal standards & practices regarding engagement with the customer/end user.

But @Thedailygrind should correct me if my interpretation is off.

We have been doing weekly blogs and email updates, as well as communication on Twitter/Facebook and technical support via support tickets. As well as bug reports via GitHub.
This seems pretty robust to me, and we are actively hiring new support people almost every other week to increase our capabilities in communication and support.
As I've said before though, we are always open to ideas if people think there is a better way we can communicate with customers.

Firstly 'weekly blog updates' is a huge stretch, and I don't think I've ever recieved an 'email' update unless a blog post has been posted.
I think there's 3 out of your 13 blog updates that are within a week of each other. It is very clear to the community that as soon as things aren't going your way it's radio silence till it is.
Even your latest is 10 days old,and I bet even if you posted it Sunday night you'd claim them to be 'weekly' because we all know you like using your own special definitions of terms to fit your actions.
Secondly, as previously mentioned by others, large amounts of people are waiting on support tickets. I personally have been waiting 10 days for a support ticket response.
My idea for better communication is investigate whoever is in charge of it because you are seemingly being lied to about their track record. Get someone who knows how to run a real business CRM program. Hiring new drones every week to answer emails off a script hasn't solved any problems as of yet.

Firstly 'weekly blog updates' is a huge stretch, and I don't think I've ever recieved an 'email' update unless a blog post has been posted. I think there's 3 out of your 13 blog updates that are within a week of each other.

Have to agree with @Thedailygrind generally speaking....the "weekly" figure felt off right away at face value, just intuitively. I can understand there being no new information to report, but it would likely still be useful to communicate that there are no new updates on the same regular schedule if for nothing other than consistency & reliability.

It is very clear to the community that as soon as things aren't going your way it's radio silence till it is.

Unfortunately whether or not this is the intention, the perception seems fairly accurate. Just to tie back to the consistency issue. People are perceptive and can pick up on narrative control, vs saying it plainly how it is regardless of how undesirable the news.

We have been doing weekly blogs and email updates, as well as communication on Twitter/Facebook and technical support via support tickets. As well as bug reports via GitHub.

It is now two weeks since the last blog post. No update on amount shipped this week. Lots of expected Batch 3 devices nowhere to be seen.
& from what appears to be even more people needing support in the discord.

We have been doing weekly blogs and email updates, as well as communication on Twitter/Facebook and technical support via support tickets. As well as bug reports via GitHub.

It is now two weeks since the last blog post. No update on amount shipped this week. Lots of expected Batch 3 devices nowhere to be seen.
& from what appears to be even more people needing support in the discord.

7 hours after your post...lol.
https://www.nebra.com/blogs/news/4th-october-shipping-production-update-instant-sync-and-more?goal=0_f4c509475a-f0940c075b-256734851&mc_cid=f0940c075b

We have been doing weekly blogs and email updates, as well as communication on Twitter/Facebook and technical support via support tickets. As well as bug reports via GitHub.

It is now two weeks since the last blog post. No update on amount shipped this week. Lots of expected Batch 3 devices nowhere to be seen.

& from what appears to be even more people needing support in the discord.

7 hours after your post...lol.
https://www.nebra.com/blogs/news/4th-october-shipping-production-update-instant-sync-and-more?goal=0_f4c509475a-f0940c075b-256734851&mc_cid=f0940c075b

It is almost funny.

However, there hasn't been any mention specifically about outdoor units in I'm guessing over 3-4 weeks.  Some other older Blog updates did call out specifically the outdoor units, but they have seemed to disappear. :-(  It's subtle unless you ordered one and don't have it yet.

However, there hasn't been any mention specifically about outdoor units in I'm guessing over 3-4 weeks. Some other older Blog updates did call out specifically the outdoor units, but they have seemed to disappear. :-( It's subtle unless you ordered one and don't have it yet.

All of our updates encompass both indoor and outdoor 👍

Unfortunately whether or not this is the intention, the perception seems fairly accurate. Just to tie back to the consistency issue. People are perceptive and can pick up on narrative control, vs saying it plainly how it is regardless of how undesirable the news.

We have shared plenty of "undesirable" news. The fact you say otherwise implies to me that you haven't really read the updates.
We provide regular updates, with both good and bad news in them. To say otherwise is beyond disingenuous.

Hiring new drones every week to answer emails off a script hasn't solved any problems as of yet.

Please refrain from derogatory comments about our staff. It does nothing of use and adds nothing to the conversation.
The vast majority of our support staff are Helium enthusiasts that have come from directly from the community and have a wealth of experience. Not all issues can be resolved in a day unfortunately - some have to be escalated to different teams for example. In any case we reply to all tickets and support requests and have done since the very beginning.

Unfortunately whether or not this is the intention, the perception seems fairly accurate. Just to tie back to the consistency issue. People are perceptive and can pick up on narrative control, vs saying it plainly how it is regardless of how undesirable the news.

We have shared plenty of "undesirable" news. The fact you say otherwise implies to me that you haven't really read the updates.
We provide regular updates, with both good and bad news in them. To say otherwise is beyond disingenuous.

Aaron, please understand there is no disrespect involved here. You are correct that there have been updates, but they have not been as routine or regular as you portray.
The point here is that there is nothing wrong with being irregular; it's the arbitrary nitpicking of details that is rubbing people the wrong way. The particulars are almost irrelevant it's the nature in which responses are received.

We have shared plenty of "undesirable" news. The fact you say otherwise implies to me that you haven't really read the updates.
We provide regular updates, with both good and bad news in them. To say otherwise is beyond disingenuous.

So previously you said the blog posts / updates were weekly. In that case, Why wasn't something posted last week?

Hiring new drones every week to answer emails off a script hasn't solved any problems as of yet.

Please refrain from derogatory comments about our staff. It does nothing of use and adds nothing to the conversation.
The vast majority of our support staff are Helium enthusiasts that have come from directly from the community and have a wealth of experience. Not all issues can be resolved in a day unfortunately - some have to be escalated to different teams for example. In any case we reply to all tickets and support requests and have done since the very beginning.

I was in no way speaking about any existing staff (as I clearly don't know them) but pointing out that your apparent practice of just hiring more people has done nothing to solve your problems.


(ant-renamer) Fix file download

Description
Ant Renamer is hosted on SourceForge. The download function fails because the file type is detected as exe/download, as with all SourceForge URLs.
Motivation and Context
Fix the broken automatic update function.
How Has this Been Tested?
Tested the update.ps1 script, which successfully updates to version 2.13.0.
Screenshot (if appropriate, usually isn't needed):
Types of changes

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Migrated package (a package has been migrated from another repository)

Checklist:

[X] My code follows the code style of this repository.
[ ] My change requires a change to documentation (this usually means the notes in the description of a package).
[ ] I have updated the documentation accordingly (this usually means the notes in the description of a package).
[ ] I have updated the package description and it is less than 4000 characters.
[X] All files are up to date with the latest Contributing Guidelines
[ ] The added/modified package passed install/uninstall in the Chocolatey Test Environment(https://github.com/chocolatey-community/chocolatey-test-environment/). Note that we don't support the use of any other environment.
[X] The changes only affect a single package (not including meta package).

:white_check_mark: Package verification completed without issues. PR is now pending human review


[Feature Request] Store IAM user credentials in keychain

I'd like to use granted with IAM users, but I'm not comfortable with storing my access tokens in plain text on disk (~/.aws/credentials) per the recommendation here https://docs.commonfate.io/granted/getting-started#set-up-your-aws-profile-file.
Would you consider a feature to store base user credentials in the keychain similar to how aws-vault works?

+1. This is especially useful/necessary for Mac-based developers where it's common to continuously download & run untrusted code (e.g. node_modules for Node.js) as the current user, so any 3rd-party code often can read ~/.aws/credentials. This attack vector is relatively common (e.g. https://blog.sonatype.com/this-week-in-malware-npm-malware-exfiltrates-windows-sam-amazon-ec2-credentials). Presumably many people considering to use granted do it because they have separate work and personal accounts, and having to store work/production secrets in plaintext should be highly discouraged.

@ipmb @eugene1g we're in the final process of adding this feature! I'd love your feedback on our CLI commands, here's a link to the docs page which adds our proposed commands.
 NAME:
    granted credentials - Manage secure IAM credentials
 USAGE:
    granted credentials command [command options] [arguments...]
 COMMANDS:
    add               Add IAM credentials to secure storage
    import            Import credentials from ~/.credentials file into secure storage
    update            Update existing credentials in secure storage
    list              Lists the profiles in secure storage
    clear             Remove credentials from secure storage, this also removes the associated profile entry from the AWS config file
    export-plaintext  Export credentials from the secure storage to ~/.aws/credentials file in plaintext
    help, h           Shows a list of commands or help for one command
 OPTIONS:
    --help, -h  show help (default: false)

Awesome, this looks great! My only nitpick is that something like remove or delete is more intuitive (opposite of add) to me than clear.
aws-vault also provides a rotate command which is super handy, but more of a nice-to-have. It's like update, but it also takes care of generating the new keys at AWS.

@chrnorm This is excellent. The only concern that I have is about this workflow -

I have an existing "hardcoded" AWS setup, with ~/.aws/config and ~/.aws/credentials
I run granted credentials import
I play around with granted and decide not to use it, or use it for a subset of profiles so I want to reset its storage after 10 minutes.
I run granted credentials clear
Concern: granted will clear ~/.aws/config and delete my original "hardcoded" setup

If this is the case, it's could be quite a footgun because it will be difficult for me to recreate that hardcoded setup if I had that file for a while. I suppose the current solution will be to ensure I run granted credentials export-plaintext, so maybe the ...credentials clear should execute in dry-run mode by default and have a --force flag before it actually overrides the static config.

@eugene1g @ipmb thanks for your feedback! This feature has been merged and will be included in the next Granted release.
We changed the clear command to be remove.
@eugene1g regarding your concerns, we've added some warnings to prompt the user to run granted credentials export-plaintext prior to running granted credentials clear. I'd be very open to additional feedback and improvement suggestions around this after the new release is shipped. I have tested a prerelease build of this and found that Granted would correctly restore ~/.aws/config entries after running granted credentials export-plaintext

@chrnorm I had to set up granted on a new computer today and went through the process of installing it and adding credentials end-to-end on a clean setup - everything worked very well for multiple AWS accounts and local browsers. Thank you!


Add signbit specification for determining whether a sign bit is set

This PR

resolves https://github.com/data-apis/array-api/issues/670 by adding a specification for signbit for determining whether a sign bit is set for each floating-point number in a provided input array.
follows Python conventions in which a boolean is returned. In C99, this is a macro which returns an integral value, where a positive result can be any non-zero integral value and a negative result must be zero.
limits the input data type to real-valued floating-point data types. The current text uses "should", indicating that array libraries may extend support to additional data types (e.g., signed integer data types) for, e.g., backward compatibility reasons. This PR does not use the more liberal real-valued data type, as the intent of this function is for distinguishing +0 and -0 and the determining the sign of NaN, values which are not possible outside of floating-point data types. For complex data types, users need to provide the real and imaginary components separately.
as this API is commonly implemented across array libraries without deviation, there are no open questions requiring resolution before specification inclusion.

One sentence I'd add to the returns section is that for negative values the result is expected to be True, and for positive values False. That won't be completely obvious otherwise to readers not familiar with the low-level details.

@rgommers Isn't that already covered in the special cases section?
    - If ``x_i`` is a positive (i.e., greater than ``0``) finite number, the result is ``False``.
    - If ``x_i`` is a negative (i.e., less than ``0``) finite number, the result is ``True``.

Ref: https://github.com/data-apis/array-api/pull/705/files#diff-153d068dcea18980d39e9465019663509adce3ee4842a48738b37a2a64c693f5R2244-R2245

I assume input shape-preserving is an implicit assumption, given that signbit just follows other elementwise docs?

@leofang That is correct. We don't explicitly mention the expected output shape across the element-wise specifications, but we should probably be explicit. I can submit a follow-up PR to address this more broadly.

Isn't that already covered in the special cases section?

No, special cases are special for a reason, and should not be needed to deduce the main behavior of a function. The text always has to make sense if you'd simply delete the special cases section.

The text always has to make sense if you'd simply delete the special cases section.

IMO this is splitting hairs. The main behavior is precisely as described, as the API should not be confused with the signum function. Meaning, using signbit to test less than or greater than zero is likely an anti-pattern; one can use one of sign, less, or greater instead. Based on a survey of docs,

PyTorch does not include the requested language.
NumPy uses misleading language. A value does not have to be less than zero in order for the sign bit to be set.
CuPy copies over the same misleading description from NumPy.
Dask copies over the same misleading description from NumPy.
JAX copies over the same misleading description from NumPy.

It is not a big ask to add something like: "if the sign bit of a value is set, i.e. has value 1 or the value has a minus sign, the result will be False". Or add the math expression like the sign function (x / |x|) for clarity. I didn't ask for fun, I needed to actually double check when I first read it.


Blueprints 7.2 DXP there is image from AC

I would say this image shouldn't go inside blueprints 7.2 DXP

https://github.com/liferay-design/liferay.design/pull/437

fixed by #437


aws-amicleaner: Resolving an issue with missing requirements

Checklist

[X] Used a fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

requirements: host: blessings==1.6 must contain a space between the name and the pin, i.e. blessings ==1.6

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

Failed to even lint the recipe, probably because of a conda-smithy bug :cry:. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Add commands related to Outlet and Shift in UserGuide

#45

Pull Request Test Coverage Report for Build 99

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

Totals

Change from base Build 98:
0.0%

Covered Lines:
1737

Relevant Lines:
1887

💛  - Coveralls


What should the custom dataset's format should look like?

Hi,
Could you let me know how the annotation file should look like in terms of how should the ground truth be labeled? Are they labeled by bounding box's coordinates or key points coordinates?
For example, to train YOLO, we put the ground truth for each picture in a .txt file, and within each .txt file, we put [class,normalized center X,  normalized center Y, normalized width, normalized height] line by line.
Thus, could you please let me know how is the annotation file should be set up? Thank you so much!
Best regards.

I have the same doubt.
Please help


Serializer Registration

This PR changes the way serializers are registered. It removes the need for serializers to be added to the :oauth2 application config.
Instead, serializers are now registered in code with OAuth2.register_serializer/2. This allows wrapper libraries to provide custom serializers without users needing to be concerned with configuring the :oauth2 application.
/cc @tsubery (#88)

Coverage decreased (-0.8%) to 94.231% when pulling 88761bbfa3040d3112c8c2e40bcd017e5f548251 on register_serializers into 6d1808c10bb0a8b7e3e26f43809c78d7e19c0356 on master.

@scrogson Recently came across a good use case here: https://github.com/ueberauth/ueberauth/issues/87.
If you don't have time, I would be happy to pick up the flag on this one.  Otherwise, I can review if you are still interested in merging this PR!

Hey @snewcomer,
I've got a new design that I want to work on that will remove the need for a centralized configuration and rely on the configuration to be on the OAuth2.Client struct itself. This will allow for greater flexibility and power.

This is looking great @scrogson.  Lmk if you need an 👁yet!

@snewcomer @doomspork I'd love some eyes on this! :heart:

@scrogson Happy Holidays homie! I will take a peek this weekend and get back to you.  Hope all is well with your family 😁

Looks great!
How does this look (references this PR)? https://github.com/ueberauth/ueberauth_google/pull/58

How does this look (references this PR)? ueberauth/ueberauth_google#58

@snewcomer hey, sorry for the delay. That PR looks like it will be perfect once this lands. Thanks for that.
I need to clean up a few things and I'll try to get it merged and a new version published.

@doomspork calling for one last review....

@scrogson was it an intentional decision that this PR changes version requirement for hackney from ~> 1.7 to ~> 1.13.0? This is a more restrictive requirement, because ~> 1.7 allows for example 1.15.1, but ~> 1.13.0 no.
I was trying to update oauth2 from 0.9.4 to 1.0.0 and this required a downgrade of hackney (along with some transitive dependencies coming from hackney). At the same time, there's no discussion in this PR related to changing hackney version requirement, so I was thinking that I'd better double-check with you. I can also open a new issue if you prefer 😄


Iterator.next() is ignored for List<Value>

This code produces an endless loop:
List<Value<Long>> releases = entity.getList("releases");
System.out.println(releases.size());    // prints 1

while (releases.iterator().hasNext()) {
	Value<Long> value = releases.iterator().next();
	System.out.println(value.get());   // prints correct value over and over
}

The condition in the while loop creates a new iterator for each iteration of the loop, which causes the infinite loop.  If you save the iterator you create before the while loop rather than creating a new one each time, the problem should be fixed.

Is this documented? Typically I don't expect a new iterator created when I simply pass a reference to it.
-----Original Message-----
From: "Ajay Kannan"<EMAIL_ADDRESS>Sent: 5/6/2016 6:57 PM
To: "GoogleCloudPlatform/gcloud-java"<EMAIL_ADDRESS>Cc: "volgin"<EMAIL_ADDRESS>"Author"<EMAIL_ADDRESS>Subject: Re: [GoogleCloudPlatform/gcloud-java] Iterator.next() is ignored forList<Value> (#993)
The condition in the while loop creates a new iterator for each iteration of the loop, which causes the infinite loop. If you save the iterator you create before the while loop rather than creating a new one each time, the problem should be fixed.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

releases is of type java.util.List (which is Iterable).  The contract of Iterable's iterator() is to return a new iterator over all items in the list.  The code you provide would also loop endlessly if you used some other generic type (e.g. Integer), like below:
List<Integer> releases = Collections.singletonList(1);
System.out.println(releases.size());

while (releases.iterator().hasNext()) {
    int value = releases.iterator().next();
    System.out.println(value);
}

OK. Thank you for a quick response, and feel free to close this issue.


Fix-up coefficients and smallest denormal value for ieeeDouble in exp()

Issue 14732 – [2.068 beta] Failing unittest in std.math

Note, though doesn't actually fix the bug. The problem is with the test itself.

Note, though doesn't actually fix the bug. The problem is with the test itself.

Can you make a pull to fix the test then?
And let's please merge this.

According to @kinke - the test works on Win64 and when using LLVM intrinsics.  However I get an "off by one" precision difference when using this function at double precision, when using glibc, and when using GCC builtins.
I think the conclusive result might be to ensure that we are accurate up to mantissa bits - 1?  This would mean that all tests would be affected.

I think the conclusive result might be to ensure that we are accurate up to mantissa bits - 1? This would mean that all tests would be affected.

I understand too little of the topic to make that decision and lack the time to go into the details.
Why would our implementation fail to deliver the correct result?
Can we already merge this PR which seems to fix some constants, then follow-up on the test failure.

Why would our implementation fail to deliver the correct result?

I don't know.  When I run the test using GDC to build, I get the same result back as when using GCC to call the libm function.  @kinke used LDC and LLVM and got back a different result (albeit, on a different platform).
It might be purely down to a conflict between compiler backends/C runtimes.


[scripts-audit WIP] vcpkg_find_acquire_program

PR-ing for CI results.

Isn't there a more declarative way for platform alternatives in JSON then if then else? After all, vcpkg doesn't need these keywords for manifests, and the use case is quite similar.

@dg0yt it's actually fairly declarative, it's just that I used $if because it makes sense and is unlikely to clash with anything.

hmm what about introducing a port for everything vcpkg-tool-<name> and slowly migrate to that instead + make vcpkg_find_acquire_program search in the dirs given by CURRENT_HOST_INSTALLED_DIR + vcpkg-tool-<name>. (Instead of this JSON migration.)

@Neumann-A that's an even bigger migration and might be the best option given all the time in the world, but this needs to be done at a decent clip.

@strega-nil-ms: I just don't see how moving from the CMake definitions to the JSON definitions is an improvement. It just feels like making it even more difficult to see what is happening.

@Neumann-A it separates data from code, which I think is good. It also, at least for me, clears up any confusion about what variables are set when.

hmm what about introducing a port for everything vcpkg-tool-<name> and slowly migrate to that instead

That's what I thought when I looked at this PR. Ports can be dependencies in manifests. Port functions are not available to users. This is source of confusion for pkgconf, flex, bison etc.
Last not least, consumers would be decoupled from changes to unrelated tools.

it separates data from code, which I think is good. It also, at least for me, clears up any confusion about what variables are set when.

Nothing against that. Just include(<tooldetails>.cmake) and prefix the variables with <TOOLNAME>_(URL|HASH|....). It just feels more natural for me to stay in CMake for this instead of switching to JSON and adding the required code for parsing the JSON.

@Neumann-A I understand the opinion... I will try switching back to CMake before this is out of draft mode.

I have to agree with the others - when I first read this JSON, I was not sure that I understood how exactly it was an improvement, considering that there are fields that are effectively cmake code instead of just declarations.

@Hoikas I think it's important that the data be pulled out from the actual code; whether that data is in JSON or in CMake, is not a big deal. I just wanted to be able to see what was going on.


Will there be a chrome version?

I never planned on it. I've never made a chrome extension and haven't used chrome in years. But I took a look at the chrome extension documentation and it didn't seem too difficult to port.
https://github.com/Cyan903/Animepahe-plus/tree/chrome-rework
Did some testing and from what I can see, all the features seem to be working properly. I'll probably need to check more things beforehand, and I doubt I'll be able to get this on the webstore. I'll try my best to get a fully functional chrome version going.

thanks a lot


Fix width/height limits in configuration errors

I forgot to include this change with my last PR to the encoder config validation.

Reopening for CI checks.


Use strict mode and let and const instead of var

Follow-up from #2251, in a branch of this repo, for ease of access.
Build passes, yay \o/ Also removed the changes to data files used by the client.
[ORIGINAL OP]
This commit also fixes some duplicated variable declarations.
It also removes the slow let hack for jshint.
Tested with iojs 2.3.3, node 4.1.0 and node 5.0.0.
It's about time we start running on strict mode, using let and const instead of var, declaring variables outside of switches, and overall moving to a better syntax.

Thanks, good job!

To you!


Implemented UPDATE

Notice: one of the tests will fail until https://github.com/src-d/go-mysql-server/pull/831 is merged in, as it is required to fix one of the bugs that that test catches.
This is an implementation of UPDATE, which brings with it a new interface. Unlike the other interfaces, this one supplies two rows, the original row, and the updated row. This decision was made so that implementations that rely on primary keys can have access to the old primary key if need be.
~Besides the big change, I've also caught a bug where supplying a non-existent column to ORDER BY will cause the query to still succeed, while ignoring the ORDER BY clause. Testing against MySQL showed that an error is the proper behavior, and this has been corrected. Since the change was small, I added it here rather than making an entirely-new PR for it.~ This was fixed by https://github.com/src-d/go-mysql-server/pull/818.

@Hydrocharged #831 merged! you can rebase when you wish. Thanks!

@ajnavarro It has been rebased!

Sorry for the delay on this one, @Hydrocharged. When rebasing, build will fail because of https://github.com/src-d/go-mysql-server/pull/835. You would probably just need to pass a *sql.Context wherever it is needed.

The *sql.Contexts have been passed around! 😄

Thank you for the contribution!


Expose fields of structs in return type of impls generated by #[derive(TryFromBits)]

Given this Rust code...
#[bitsize(32)]
#[derive(TryFromBits)]
struct Example {
    foo: bool,
    bar: u24,
    baz: Kind,
}

#[bitsize(7)]
#[derive(TryFromBits)]
enum Kind {
    First,
    Second,
    Third,
}

let data: u32;

...the return type of Example::try_from(data) and data.try_into() is Result<Example, u32>. I think having a return type of Result<Example, (bool, UInt<u32, 24>, UInt<u8, 7>)>, exposing the fields of Example, is better. Essentially, structs become tuples of their fields, and enums become their arbitrary_int::UInt representations.
Motivation
impl ParseError {
    fn new(flag: u8) -> Self { ... };
}

I'm using this crate to parse flags in file headers. $n$ bits in one section are converted to an enum. However, not all possible values of $n$ bits correspond to enum variants, so this conversion is fallible. In case of failure, I'd like to return a ParseError from my own crate, mentioning the bits that failed to convert. However, I couldn't find an easy way to get these bits.
When the conversion fails, the original value is returned. I necessarily have access to this value—otherwise, the conversion could not be attempted in the first place—so why is it returned? The docs mention that "... TryFrom ... semantics are very clear," so if there's a good reason for this, I would like to know. I came up with two workarounds for now.
First workaround: bit manipulation
let flags: Example = data
    .try_into()
    .map_err(|n: u32| {
        let flag = ((data >> 25) & 127u32) as u8;
        ParseError::new(flag)
    })?;

This is relatively concise, but doing manual bit manipulations defeats the purpose of the crate.
Second workaround: convert twice
#[bitsize(32)]
#[derive(FromBits)]
struct RawExample {
    foo: bool,
    bar: u24,
    baz: u7,
}

struct Example {
    foo: bool,
    bar: u24,
    baz: Kind,
}

enum Kind {
    First,
    Second,
    Third,
}

impl TryFrom<RawExample> for Example {
    type Error = ParseError;

    fn try_from(value: RawExample) -> Result<Self, Self::Error> {
        let kind = match value.baz().value() {
            0 => Ok(Kind::First),
            1 => Ok(Kind::Second),
            2 => Ok(Kind::Third),
            flag => Err(ParseError::new(flag)),
        }?;

        Ok(Self {
            foo: value.foo(),
            bar: value.bar(),
            baz: kind,
        })
    }
}

let flags: Example = data
    .into()
    .try_into()?;

This preserves the safety provided by the crate, but the boilerplate seems unnecessary.

Hello there! From and TryFrom are both used for parsing raw values and From is also used for getting back the underlying raw value again. I should mention these semantics somewhere instead of saying they're obvious, though.
The problem with returning the fields in try_from would be that we'd need to keep parsing the raw value after we've found an error, which might not be what everyone wants. Let's consider an alternative:
I think we solved your usecase half-way a few weeks ago, by adding this:
https://github.com/hecatia-elegua/bilge/blob/main/README.md?plain=1#L121-L150
The plan would be to extend this to also allow:
#[fallback]
Reserved(uN),

where N is the bitsize of the enum.
This way you would match Kind::Reserved(flag) => ParseError::new(flag)?.

Another case against returning the value in theErr case: normally this is done to return ownership of the value that failed to convert instead of consuming it. Which doesn't really make sense when converting numbers, since the converted value is always going to be Copy and so won't be consumed.
I agree that the solution using #[fallback] would work for your usecase, but that's because your struct has only one fallible field. In other words, you know ahead of time that if try_from() failed, it's because of an invalid value for baz.
But what if you had two? Returning a big tuple or a "raw" struct doesn't actually help here, since you'll have to manually check each fallible field (though you do get to skip the task of extracting the value). As @hecatia-elegua said we also want to stop parsing after the first failure.
We can return the range of bits that had an unexpected value (or start bit + length), possibly along with the name of the field. That would make it pretty easy for the user to extract the invalid bits, but as @astral4 mentioned, breaks the abstraction of no manual bit manipulation.
Here's an idea (which may be infeasible, just guessing here): given a struct
#[bitsize(32)]
#[derive(TryFromBits)]
struct Example {
    foo: u5,
    this_one_can_fail: u24,
    this_one_can_also_fail: u2,
    bar: bool,
}

we also generate something like
enum ExampleConversionFailure {
    ThisOneCanFail(u24),
    ThisOneCanAlsoFail(u2),
}

and then the signature of Example::try_from would be Result<Example, ExampleConversionFailure>.

@pickx yup, so removing the raw value from Err in some upcoming version would be good. I mean, if we can fill it in with something more useful.
For your idea, I think we would need annotations on the fallible fields to do so (or find some kind of type system magic instead of using FILLED to differenciate between From/TryFrom fields). I still like it, just noting this.
Also, maybe I didn't understand, but #[fallback] Reserved(uN) would work for multiple fields, no?
It is bulkier, there's a trade-off between "I want to only access one-two fields in one place and there can be reserved/filler values" and "I want to access the whole thing or catch the exact error directly after parsing".
//u8
struct Example {
    foo: Enum1, //u2
    bar: Enum2, //u4
    baz: Enum3, //u2
}
fn main() {
    let e = Example::from(0b11_1111_11);
   // sth like this, depends on what you're doing
    match e.foo {
        Enum1::Reserved(v) => ParseError::new(v.value()), //or handle the value
        //...
    }
    match e.bar{
        Enum2::Reserved(v) => ParseError::new(v.value()), //or handle the value
        //...
    }
   //...
}

vs.
//u8
struct Example {
    foo: Enum1, //u2
    bar: Enum2, //u4
    baz: Enum3, //u2
}
fn main() {
    let e = Example::try_from(0b11_1111_11);
   // sth like this, depends on what you're doing
    match e {
        Err(ExampleErr::Foo(v)) => ParseError::new(v.value()), //or handle the value
        Err(ExampleErr::Bar(v)) => ParseError::new(v.value()), //or handle the value
    }
}

@astral4 do you have more code with a similar need? And which one would you prefer in your case?

So the first one it is! Not sure when I'll be adding that.
About name clashing in the other approach:
The user could name-clash on ExampleErr, but tbh then I would just add a way to define the error name if really necessary.
Or we could have a generic error type, sth like:
pub struct TryFromBitsErr<T>(pub T);

fn main() {
    let e = Example::try_from(0b11_1111_11);
    // sth like this, depends on what you're doing
    match e {
        Ok(example) => //...
        Err(TryFromBitsErr(ExampleErr::ThisOneCanAlsoFail(e))) => e.value() as u32,
        Err(TryFromBitsErr(ExampleErr::ThisOneCanFail(e))) => e.value(), //...
        //...
    }
}

of course this looks a bit ugly, also nesting TryFrom is not solved by this

@astral4 thanks to @pickx we've now got support for
#[fallback]
Reserved(uN),

in the github main branch (will not release to crates.io immediately), feel free to try it.

Closing for now, error type might be relevant again later.


Can add Zabbix as Datasource in Grafana

Hello,
I've been using Grafana (v7.3.1) for a while now and have many data sources connected to it. I've been asked to add Zabbix as a data source and I am having trouble.
We are using the free Zabbix appliance 5.2.1 in VMware and I've added a few devices to monitor.
I've been trying so many ways to add it as a data source and all fail.
I know the API account works as I can log into it.
If I go to http://x.x.x.215/zabbix/api_jsonrpc.php I get a File Not Found which I think is correct

Any ideas where I'm being stupid?
Thanks

by   changing    /zabbix/api_jsonrpc.php  into  api_jsonrpc.php .   just  like    http://x.x.x.215/api_jsonrpc.php.        i  got  the problem  solved.
LOL.  i guess   api  has been  updated

Hmm that didn't work for me either, what other settings are you using in your data source please as I must of got something else wrong in there?

still 404 file not found?
your   Zabbix appliance is 5.2.1 ...      you  should  use     http://x.x.x.215:8080/api_jsonrpc.php  instead.    start from zabbix-sever 4.0.X（maybe ，i am not quite  sure ）.   the default 80 has changed to 8080,

Why do you use Browser mode? It's deprecated, use server instead. Make sure you configured proper URL for the zabbix api.


[PORT] Hardened prompts

Port this change from botbuilder-dotnet/master branch:
https://github.com/microsoft/botbuilder-dotnet/pull/3949

See parent PR: https://github.com/microsoft/botbuilder-js/pull/2246
Description
Some of the prompts break if user uploads an attachment instead of responding with text because of some of the string methods that get called on activity.text (which doesn't exist if an attachment is sent).
Specific Changes
Add some variation of
if (string.isNullOrEmpty(turnContext.Activity.Text)) {
  return Task.FromResult(result);
}

to:

ChoicePrompt
DatetimePrompt
NumberPrompt
ConfirmPrompt

I also renamed message to utterance to be more in line with other prompts.
The original issue was only for DatetimePrompt, but I added the other two. Other prompts didn't seem relevant for this.
Changed projects

Microsoft.Bot.Builder.Dialogs

Already covered in original PR: https://github.com/microsoft/botbuilder-js/pull/2246


version 3

pull request for tracking progress of major version 3 of this library.
Features:

dropped support for callbacks. All methods return promises.
uses nba-client-template as a model for authors of NBA API clients in other languages.
added synergy namespace endpoints
endpoint methods have parameters and defaults fields to show how to use them
simple command-line interface
vastly improved, auto-generated documentation

Coverage decreased (-1.7%) to 74.39% when pulling c56c2567d372ed89930022ddc6796e3016d354fa on v3 into fe5fe3caecf6a16621eadb432a54dcfe42f0daef on master.

Coverage decreased (-1.7%) to 74.39% when pulling c56c2567d372ed89930022ddc6796e3016d354fa on v3 into fe5fe3caecf6a16621eadb432a54dcfe42f0daef on master.


ENH: Add butterfly channel picking

Closes #2071.
Ready for testing / review / merge @teonlamont.

it works really well. is there a way to make the text the top layer in maybe a different color? if you click in a place where there are surrounding, the text gets washed out.
do we want it to have the behavior like raw.plot() where you click the channel, it's marked as bad and you toggle it on and off for multiple channels?

I got one error but it's when I clicked on the plot with no close by channels:
In [11]: Traceback (most recent call last):
  File "/Users/teon/anaconda/lib/python2.7/site-packages/matplotlib/backends/backend_qt5.py", line 263, in mousePressEvent
    FigureCanvasBase.button_press_event(self, x, y, button)
  File "/Users/teon/anaconda/lib/python2.7/site-packages/matplotlib/backend_bases.py", line 1887, in button_press_event
    self.callbacks.process(s, mouseevent)
  File "/Users/teon/anaconda/lib/python2.7/site-packages/matplotlib/cbook.py", line 540, in process
    proxy(*args, **kwargs)
  File "/Users/teon/anaconda/lib/python2.7/site-packages/matplotlib/cbook.py", line 415, in __call__
    return mtd(*args, **kwargs)
  File "mne/viz/evoked.py", line 48, in _butterfly_on_button_press
    if params['need_draw']:
KeyError: 'need_draw'

Fixed the clicking bug and the text display, see if you're happy now.
I'm -1 on making this a bad channel setter. It is better to do bad channel selection at the raw stage since things like projector calculation and ICA will change depending on which channels are marked bad.

works like a charm for me but travis complains
thanks @Eric89GXL !

sweet. works great :)

thanks @Eric89GXL!

@jaeilepp do you want to participate in code review here? Seems relevant to the GSoC

Coverage decreased (-17.0%) to 73.32% when pulling 3d15ddf89e7902f4c98f79590a24b3988cca47b1 on Eric89GXL:line-pick into 7f8071891d7a8c2fdaa61ea3a8819394fcd86de2 on mne-tools:master.

@teonlamont in case you didn't notice I made it so that clicking away from all the channels removes the text.
Turns out that we weren't actually using old numpy/scipy before because subsequent calls to conda install were updating those packages. I made changes to .travis.yml fix it in this PR. Then I made some other scattered changes to fix for code for those old versions of numpy and scipy now that we actually test them.
Ready for review/merge.

I'd like to make sure we're not silently bumping minimum numpy version but besides +1 for merge.

Had to bump it, 1.6 doesn't work (library error), if you want to see it
look at the Travis run before the version bump

Specifically:
https://travis-ci.org/mne-tools/mne-python/jobs/61931138#L176

Bumping numpy version will have impact on Debian packaging :(
Is there a way to avoid it?

On 10 mai 2015, at 14:23, Eric Larson<EMAIL_ADDRESS>wrote:
Specifically:
https://travis-ci.org/mne-tools/mne-python/jobs/61931138#L176
—
Reply to this email directly or view it on GitHub.

No no no, the version is only bumped in Travis, not as a requirement for the package. We have never run the oldest versions in Travis anyway because they are not available (e.g., scipy's oldest available is 0.11 but we only require something like 0.9).

...and we weren't actually even running numpy 1.6 before in Travis, we were using 1.8 or 1.9 because it got auto-installed by recommendations from later conda install commands.

Ok good. Merge when Travis is happy

@agramfort I pushed a commit to address #2015, do you want to have another quick look or are you okay with it?

Specifically: https://github.com/mne-tools/mne-python/commit/236df09164402be6be0dcd754f7deaee0d097854

Ok when Travis is happy


Can't play Youtube song

I get this error message
INFO     Need 11 character video id or the URL of the video. Got //youtube:video/kidd funkadelic - maggot brain.3aAzdHnYfuk
ERROR    YoutubeBackend backend returned bad data: Expected a list of Track, not [None]

Hey ive got the same issue........

This might be related to #70.
What happens if you install youtube-dl with pip install youtube-dl and try again?

Thanks @jcass77 but im still getting this error...im sure it was playing youtube videos 2-3 days ago..
INFO     Need 11 character video id or the URL of the video. Got //youtube:video/Taco - Puttin on the Ritz (Original Uncensored Version).OG3PnQ3tgzY
ERROR    YoutubeBackend backend returned bad data: Expected a list of Track, not [None]

Yes, I also got the same error and was working few days before. Please fix this issue ASAP.
Thanks !

I have the same problem, but i can play song @PJkeeh posted and cannot play the one @ginandtronic posted.
also i have different error:
WARNING  Track is not playable: youtube:video/Taco - Puttin on the Ritz (Original Uncensored Version).OG3PnQ3tgzY
i'm using 2.0.0-2 (from apt) version

ok, i removed mopidy-youtube and pafy from the system then installed mopidy-youtube with pip (2.0.2 version) and the problem is gone :)

but this is dirty @mczerski , with this you can't search youtube's videos with mpc. I have installed youtube-dl with pip and can't play .OG3PnQ3tgzY (Taco's song) too. I use Mopidy on Orange Pi Zero with Armbian jessie.

and more I removed mopidy-youtube and I installed with pip 2.0.2 and then don't play this song .OG3PnQ3tgzY

OG3PnQ3tgzY has been removed from YouTube and Mopidy 3 / Mopidy-Youtube 3 plays 3aAzdHnYfuk, so closing this issue.


ONLY NON-FAKE STARS, PLEASE!!!

We are very happy with all the sincere github stars we get.
But it has drawn my attention that at 6/2/2018 6 stars were added, all with similar names, all with icons rather than pictures and all with the same joining date.
This could be a coincidence, but it also could point to someone attempting to support us in this way.
In that case: PLEASE DON'T DO THIS, AS IT WILL SEVERELY DAMAGE THE INTEGRITY OF THE PROJECT!
If my analysis with regard to this is correct, please be so kind as to remove these 6 stars.
If you want to contribute to its popularity, tell colleagues, write about it, use it, contribute to it.
But things like signaled above are off limits.
Jacques

@JdeH Sounds like a bot.

I don't like this at all.
I've sent GitHub a request to remove these stars.
Transcrypt absolutely doesn't need any trickery like this.

@JdeH Isn't it a responsibility of Github to detect spam and act accordingly ?

I don't know, I just know I don't want to spend any more energy on this.
So I continue programming.

GitHub has settled the matter to satisfaction.
Issue closed...


Go-JSON Replacement

What does this PR change?

Replaces json-iter library with go-json: https://github.com/goccy/go-json

The json-iter library has a show-stopping bug which will degrade performance of the go runtime almost to a full stop. See this issue for details: https://github.com/json-iterator/go/issues/603
go-json seems to have a more active maintainer

How does this PR impact users? (This is the kind of thing that goes in release notes!)

Fix for requests which don't receive responses.

How was this PR tested?

Using several specific benchmarks that repro'd the bug case in json-iter
All kubecost ETL structure json encode/decode unit tests are passing.

Were we able to test this on the scale cluster for possible performance regressions?


Cascade Terminate/Purge for workflow

Describe the feature
Cascade terminate/purge feature for workflow has been added in Dapr runtime. It is enabled by default and can be disabled by passing non_recursive=True in the terminate/purge request.
SDK needs to expose this option to customer.
Reference:

https://github.com/dapr/dapr/pull/7340
https://github.com/microsoft/durabletask-go/pull/47
https://github.com/microsoft/durabletask-dotnet/issues/260

Release Note

RELEASE NOTE:

PR to support cascade terminate/purge in durabletask-dotnet: https://github.com/microsoft/durabletask-dotnet/pull/262
After this gets merged, will create the PR to surface the option here.

/assign

I've added the breaking change label here because this is technically a change in core behavior that the user can't opt into. I do understand that this is the desired path so it's more of a bugfix than anything else, but we need to advertise that.

Closed by #1243


⚠ TorrentLeech has degraded performance

In 6e3a28d, TorrentLeech ($TL) experienced degraded performance:

HTTP code: 200
Response time: 9162 ms

Resolved: TorrentLeech performance has improved in fcbeb8e after 32 minutes.


Hack for JP iTunes and Unicode Metadata Support

Ideally, we'd use RichPresenceNative wrappers instead of the RichPresence ones and the same logic I used here, but this works (feel free to make the needed changes to use IntPtr instead of string into RichPresenceNative and not accepting this PR). I also added logic for the Japanese Music playlist (ミュージック), but other playlist names could be necessary.

Hey, thanks for fixing that issue! I'll test out your pull request within a week or two to ensure everything works, and then I'll go ahead and merge it.


Replace asserts in sign()

This PR replaces asserts in sign() with if not ...: raise ....  Sometimes assert is omitted in an optimised execution, but input checks should be always performed.
This PR is a part of #847.
I expect a CodeCov failure, and then I'll add tests to cover the new paths.

Now I'll write tests where sign() is called with

a message that's not a byte sequence
a message that's not exactly 32 bytes long
a private key that's not a string
v not being 0 or 27.


generate_practice_exercise

I have noticed that when I run this script, the ert tests frequently have a non valid name. Something like:
(ert-deftest combination-of-lower-and-uppercase-letters,-punctuation-and-white-space ())
So obviously the comma should not be there. This is not a huge issue but I just thought I would document it incase we want to fix it.

@kmarker1101 Thanks for reporting! Should be fixed. :)


updates

NOTE
Please verify that the base repository above has the intended destination!
Github by default opens Pull Requests against the parent of a forked repository.
If this is your personal fork and you didn't intend to open a PR for contribution
to the original project then adjust the base repository accordingly.

Oh gosh, I'm so sorry! I'll delete the PR!


Bot does not respond to "/report" command to a user after he reports more than "report_cooldown" time ago

Resolved


Add tests for FeatureDataTypeSelectorFragment

@shobhitagarwal1612 PTAL

/gcbrun

/gcbrun

Codecov Report

Merging #1097 (c481fb8) into master (e9cbeed) will increase coverage by 0.00%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1097   +/-   ##
=========================================
  Coverage     29.14%   29.14%
  Complexity      725      725
=========================================
  Files           271      271
  Lines          6980     6979    -1
  Branches        291      291
=========================================
  Hits           2034     2034
+ Misses         4858     4857    -1
  Partials         88       88

Impacted Files
Coverage Δ

...ntainer/FeatureDataTypeSelectorDialogFragment.java
0.00% <0.00%> (ø)

Continue to review full report at Codecov.

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

Huh, do you think that file was already covered by other tests @shobhitagarwal1612? I'm surprised that there was no impact on code coverage.

Have you tried looking at the code coverage for that file locally? It should be somewhere under jacoco/ directory.

/gcbrun

Since the CodeCov report may be innaccurate because it wasn't calculating the coverage for @AndroidEntryPoints classes before, here are the before and after results for the mapcontainer directory.
Before:

After:

So the coverage was increased by 4% from 16% to 20%


Error when running example

Thank you for making this code available. After I installed pc-Skeletor from pip,  I met an error when running example:
skeleton, graph, skeleton_graph = skeletor.extract(method='Laplacian', config=laplacian_config) ValueError: not enough values to unpack (expected 3, got 2)
Are you have any suggestions for me?

Hi @lacie-life,
I think I forgot to update all examples during my last change. Nevertheless use the branch s-lbc for a new version. It is a revised version and will be released to pypi in the next weeks.


HDDS-2128. Make ozone sh command work with OM HA service ids

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
40
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

-1
test4tests
0
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.

_ trunk Compile Tests _

-1
mvninstall
31
hadoop-ozone in trunk failed.

-1
compile
22
hadoop-ozone in trunk failed.

+1
checkstyle
51
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
814
branch has no errors when building and testing our client artifacts.

-1
javadoc
18
hadoop-hdds in trunk failed.

-1
javadoc
18
hadoop-ozone in trunk failed.

0
spotbugs
146
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
26
hadoop-ozone in trunk failed.

_ Patch Compile Tests _

-1
mvninstall
33
hadoop-ozone in the patch failed.

-1
compile
25
hadoop-ozone in the patch failed.

-1
javac
25
hadoop-ozone in the patch failed.

+1
checkstyle
56
the patch passed

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
650
patch has no errors when building and testing our client artifacts.

-1
javadoc
17
hadoop-hdds in the patch failed.

-1
javadoc
18
hadoop-ozone in the patch failed.

-1
findbugs
27
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
127
hadoop-hdds in the patch failed.

-1
unit
28
hadoop-ozone in the patch failed.

+1
asflicense
34
The patch does not generate ASF License warnings.

2735

Reason
Tests

Failed junit tests
hadoop.ozone.container.keyvalue.TestKeyValueContainer

hadoop.ozone.container.ozoneimpl.TestOzoneContainer

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1445

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

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

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 6a9f7ca

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/branch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/branch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/branch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/branch-findbugs-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/patch-compile-hadoop-ozone.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/patch-javadoc-hadoop-hdds.txt

javadoc
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/patch-javadoc-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/testReport/

Max. process+thread count
411 (vs. ulimit of 5500)

modules
C: hadoop-ozone/ozone-manager U: hadoop-ozone/ozone-manager

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

The patch is complete with an integration test at this point. Please kindly review @bharatviswa504 @arp7 @hanishakoneru . Thanks.

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
45
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

0
mvndep
28
Maven dependency ordering for branch

-1
mvninstall
30
hadoop-ozone in trunk failed.

-1
compile
21
hadoop-ozone in trunk failed.

+1
checkstyle
58
trunk passed

+1
mvnsite
0
trunk passed

+1
shadedclient
816
branch has no errors when building and testing our client artifacts.

+1
javadoc
148
trunk passed

0
spotbugs
166
Used deprecated FindBugs config; considering switching to SpotBugs.

-1
findbugs
26
hadoop-ozone in trunk failed.

_ Patch Compile Tests _

0
mvndep
18
Maven dependency ordering for patch

-1
mvninstall
34
hadoop-ozone in the patch failed.

-1
compile
27
hadoop-ozone in the patch failed.

-1
javac
27
hadoop-ozone in the patch failed.

-0
checkstyle
29
hadoop-ozone: The patch generated 1 new + 29 unchanged - 1 fixed = 30 total (was 30)

+1
mvnsite
0
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
657
patch has no errors when building and testing our client artifacts.

+1
javadoc
151
the patch passed

-1
findbugs
24
hadoop-ozone in the patch failed.

_ Other Tests _

-1
unit
139
hadoop-hdds in the patch failed.

-1
unit
25
hadoop-ozone in the patch failed.

+1
asflicense
33
The patch does not generate ASF License warnings.

3092

Reason
Tests

Failed junit tests
hadoop.ozone.container.keyvalue.TestKeyValueContainer

hadoop.ozone.container.ozoneimpl.TestOzoneContainer

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1445

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

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

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / 85b1c72

Default Java
1.8.0_222

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/branch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/branch-compile-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/branch-findbugs-hadoop-ozone.txt

mvninstall
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/patch-mvninstall-hadoop-ozone.txt

compile
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/patch-compile-hadoop-ozone.txt

javac
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/patch-compile-hadoop-ozone.txt

checkstyle
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/diff-checkstyle-hadoop-ozone.txt

findbugs
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/patch-findbugs-hadoop-ozone.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/patch-unit-hadoop-hdds.txt

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/artifact/out/patch-unit-hadoop-ozone.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/testReport/

Max. process+thread count
426 (vs. ulimit of 5500)

modules
C: hadoop-ozone/ozone-manager hadoop-ozone/integration-test U: hadoop-ozone

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1445/2/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.


setup: fail gracefully if package.json cannot be found

closes #751, follow up for #752

this is ready for review ping @hoodiehq/maintainers

fixed via https://github.com/hoodiehq/hoodie/commit/79dde6b8c4151d803aea0a1e58463d3ad6c06663


Move test dependencies to requirements.txt

Is your feature request related to a problem? Please describe.
The test dependencies are only installed when running the ci. So, if the user runs pip install requirements.txt, they won't be installed, and he needs to install manually.
Describe the solution you'd like
Add the test dependencies to requirements.txt

I'll knock this out real quick. I only left it seperated for the exact opposite reason. I was thinking a user shouldnt be bogged down with dependencies they might not use, but I understand why we should include them in a single requirements.txt.

Closed by #57


Loading another Dockerfile that is located further up the tree than "just the parent directory" seems to fail

Hi,
I'm trying to hook up a I am trying to extend a Dockerfile that's shared between projects here at work, but loading that Dockerfile - located further up the tree than "just the parent directory" - seems to fail. Can you tell me what I'm doing wrong / is not supported?
Our Docker Container repository is a monorepo which contains docker-compose builds for our projects, along with some default builds for Apache and PHP.

My docker-compose.yml is located in repository/my-project/apache/docker-compose.yml
Which in turn picks the Dockerfile at repository/my-project/apache/apache/Dockerfile
This one should load the "Apache Base Instructions" from repository/apache/apache/Dockerfile

Contents of my Project-specific Apache Dockerfile:
# syntax = devthefuture/dockerfile-x
# This syntax is required to use FROM

FROM ../../../apache/apache/Dockerfile
# Trying ../../apache/apache/Dockerfile (relative from docker-compose.yml, and building in there) fails as well...

RUN my-command-to-run-at-buildtime (mkdir && ln -s)

CMD commands-to-start && httpd-foreground (actually, this is copying the last line from ../../../apache/Dockerfile)

Running docker build -t test . in the directory where my Dockerfile is located, always ends up to this output, regardless of the path I set at FROM
docker build -t test .
[+] Building 3.3s (7/7) FINISHED
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load build definition from Dockerfile                                                                                0.1s
 => => transferring dockerfile: 283B                                                                                0.0s
 => resolve image config for docker.io/devthefuture/dockerfile-x:latest                                                                                1.8s
 => CACHED docker-image://docker.io/devthefuture/dockerfile-x@sha256:e4916e77d6f4b37b1daf049fa3e7162294f8f3a28497178112cf828fc8f3ee5e                                                  0.0s
 => local://dockerfile (Dockerfile)                                                                                0.0s
 => => transferring dockerfile: 283B                                                                                0.0s
 => local://context (../apache/apache/Dockerfile)                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => local://context (../apache/apache/Dockerfile.dockerfile)                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
Dockerfile:1
--------------------
   1 | >>> # syntax = devthefuture/dockerfile-x
   2 |     # This syntax is required to use FROM
   3 |
--------------------
ERROR: failed to solve: failed to execute dockerfile-x: failed to read dockerfile '../apache/apache/Dockerfile.dockerfile': open /var/lib/docker/tmp/buildkit-mount1187487370/apache/apache/Dockerfile.dockerfile: no such file or directory
, Output:

It seems the script does not go back more than one directory up the directory tree, it ignores every extra ../ I add to the path at FROM...
When "just using a copy of the original file nd amending my own changes" - essentially bypassing dockerfile-x - the container gets built without issues.

The buildkit frontend have a by design limitation that doesn't allow to get file outside of the context of the build (the context, not the directory of the dockerfile).

Thanks for your reply. So, if I get you correctly, that would imply that setting the context in docker-compose.yml to the root of our compose-repository would fix the imports?
-------- Oorspronkelijk bericht --------
Op 31 dec. 2023 11:02, schreef Jo :

The buildkit frontend have a by design limitation that doesn't allow to get file outside of the context of the build (the context, not the directory of the dockerfile).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

Thanks for your reply. So, if I get you correctly, that would imply that setting the context in docker-compose.yml to the root of our compose-repository would fix the imports? -------- Oorspronkelijk bericht -------- Op 31 dec. 2023 11:02, schreef Jo :
…
The buildkit frontend have a by design limitation that doesn't allow to get file outside of the context of the build (the context, not the directory of the dockerfile). — Reply to this email directly, [view it on GitHub](#6 (comment)), or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

Yes it should

This is really something that should be mentioned in the documentation already here: https://github.com/devthefuture-org/dockerfile-x?tab=readme-ov-file#from-with-relative-paths since people often want to do this if they go with a directory structure of /base/specificCase/evenMoreSpecificCase...


Show encryption info

Hello! Thanks for this library.
qpdf allows us to do this:
$ qpdf --show-encryption file.pdf
V = 5
R = 6
P = -4
Has user password: no
Has owner password: yes
User password =
extract for accessibility: allowed
extract for any purpose: allowed
print low resolution: allowed
print high resolution: allowed
modify document assembly: allowed
modify forms: allowed
modify annotations: allowed
modify other: allowed
modify anything: allowed
stream encryption method: AESv3
string encryption method: AESv3
file encryption method: AESv3

It would be great to wrap this with node-qpdf2 as well

Sure, I've got a prototype built. What are you looking for in this info, just the string output, or do you think it's important to have the string parsed? Might be a little difficult because there are two different ways to split the data in the results, both = and : are used.

@Sparticuz thank you! I was mostly interested in finding out whether a pdf is encrypted or not. The rest of the information is not as important. I am building an app where the interaction will look like this:

A user uploads a file
If the file is an encrypted pdf we tell that to the user
The user can click on a prompt and enter the file's password
Our app uses that to decrypt the pdf and store the decrypted version

Thanks again for your help

I merged the PR, but i most likely won't be able to cut a new release until tomorrow.

@Sparticuz thank you and that is completely fine


Fix the install_sslyze.sh Script to work on fresh Ubuntu 16.04 install

Issue # (if available): N/A
Description of changes:
Attempted to install s2n on a fresh Ubuntu 16.04 VM and ran into an error in the install_sslyze.sh script. Upgrading pyOpenSSL before attempting to upgrade pip and setuptools fixed the issue.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Tested on a fresh ubuntu machine, failed before, tried this and it worked.


Remove unused variable in CFStringUtilities.c

@swift-ci test

@millenomi lmk if you'd like to review trivial PRs such as this, or I could merge them otherwise

I have these patches on temporary pause — the Core Foundation sources in this repo are produced by processing other source. Historically, every fall we merge in code to master from new releases, and I'm in the middle of figuring out how to do that for this year, and each small change adds some burden to that.
As soon as the new merge-in PR is posted, these then become good to merge.

How may I know that we could move further? I see a lot of other things like these ones which could and should be fixed.

ping

ping

ping @spevans

Any update on this @parkera

ping

Thanks!


Add fudan nlp datasets

Hi, @neubig
This script will be potentially useful in the future when you aim to add NER task to cmu_anlp.

Thanks!


Unable to supersede IdentityToZeroTransformation and NullToZeroTransformation

What went wrong?
Both IdentityToZeroTransformation and NullToZeroTransformation are to handle special instances where LinearTransformer is used to map Numeric columns, but the values are either identical or all null. Ideally, these should be superseded when appending "regular" data by LinearTransformation instances. For now, it is not the case.
How to reproduce?
For IdentityToZeroTransformation for instance(and similarly for NullToZeroTransformation):
import org.apache.spark.sql.delta.DeltaLog
import io.qbeast.spark.delta.DeltaQbeastSnapshot
import io.qbeast.core.transform.IdentityToZeroTransformation
import spark.implicits._

case class IdentityCls(col1: String, col2: Int, col3: Double)

val idTestPath = "/tmp/test1/"
val identityData = (1 to 1000).map(_ => IdentityCls("1", 1, 1d)).toDS()
(identityData
	.write
	.mode("overwrite")
	.option("columnsToIndex", "col2")
	.option("cubeSize", "10000")
	.format("qbeast")
	.save(idTestPath)
)

(DeltaQbeastSnapshot(DeltaLog.forTable(spark, idTestPath)
  .update())
  .loadLatestRevision
  .transformations
  .head
  .isInstanceOf[IdentityToZeroTransformation]
) // true

// scala.MatchError at io.qbeast.core.transform.IdentityToZeroTransformation.transform(Transformation.scala:56)
((1 to 1000)
  .map(i => IdentityCls(s"$i", i, i.toDouble))
  .toDS()
  .write
  .mode("append")
  .format("qbeast")
  .save(idTestPath)
)

2. Branch and commit id:
main, f066acf
3. Spark version:
3.4.1
4. Hadoop version:
3.3.4
5. How are you running Spark?
Locally

My initial thoughts on this:

IdentityTransformation should NOT be superseded by another IdentityTransformation. (By definition, the space value of Identity A is not considered in Identity B unless value a and value b are the same).
IdentityTransformation should NOT superseded by a NullToZeroTransformation. Same case as the Identity.
IdentityTransformation might be superseded by a LinearTransformation if max and min cover the identity value.

Now, in cases 1 and 2, we might require a trigger of another type of transformation, such as LinearTransformation, in which we include values from A and B as the ranges.
Does it make sense?

The creation of NullToZeroTransformation and IdentityToZeroTransformation
The LinearTransformer creates both NullToZeroTransformation and IdentityToZeroTransformation when the input column has only one unique value:

NullToZeroTransformation when it's full of nulls
IdentityToZeroTransformation otherwise

What does superseding a Transformation mean?
If a transformation t1 is superseded by another transformation t2, t1.isSupersededBy(t2),it means that the space oft2is not contained in that oft1and a larger transformationt3 = t1.merge(t2)` should be used instead.
How to define isSupersededBy?
NullToZeroTransformation can only transform nulls, so it should be superseded as soon as any other transformation is encountered.
It should be superseded by:

IdentityToZeroTransformation
LinearTransformation

And not by:

NullToZeroTransformation

IdentityToZeroTransformation(a) should be superseded by:

NullToZeroTransformation
A different IdentityToZeroTransformation(b) where a != b.
A LinearTransformation(c, d) where a != c.

How do we merge?
NullToZeroTransformation.merge(IdentityToZeroTransformation) => ?
NullToZeroTransformation.merge(LinearTransformation) => ?
NullToZeroTransformation.merge(NullToZeroTransformation) => ?
IdentityToZeroTransformation.merge(NullToZeroTransformation) =>  ?
IdentityToZeroTransformation.merge(IdentityToZeroTransformation) => ?
IdentityToZeroTransformation.merge(LinearTransformation) => ?
What do we do if there are only two values: null and some_value?


Use of GK's links pagination

The Gatekeeper module will provide pagination links so it's needed to include them in the son-bss code

Clossed: #55


Error running program

An error occurred.  Details to follow:

System.FormatException: The string was not recognized as a valid DateTime. There is an unknown word starting at index 0.
   at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
   at GetSqlServerVersionInfo.SqlServerBuild..ctor(List`1 cells, String majorVersionName) in C:\Users\edarl\Downloads\SqlServerVersionScript-master\SqlServerVersionScript-master\src\GetSqlServerVersionInfo\SqlServerBuild.cs:line 16
   at GetSqlServerVersionInfo.Program.GetSqlServerBuildsFromMicrosoftWebsite(IReadOnlyCollection`1 supportDates) in C:\Users\edarl\Downloads\SqlServerVersionScript-master\SqlServerVersionScript-master\src\GetSqlServerVersionInfo\Program.cs:line 142
   at GetSqlServerVersionInfo.Program.TryMain(String[] args) in C:\Users\edarl\Downloads\SqlServerVersionScript-master\SqlServerVersionScript-master\src\GetSqlServerVersionInfo\Program.cs:line 34
   at GetSqlServerVersionInfo.Program.Main(String[] args) in C:\Users\edarl\Downloads\SqlServerVersionScript-master\SqlServerVersionScript-master\src\GetSqlServerVersionInfo\Program.cs:line 17

Thanks, Erik!  There is a typo in the source data:

Septmeber 20, 2018

I'm on the fence about how to fix this in the meantime.  I'm thinking either:

add temporary code to handle that specific typo, or
put some kind of default date (1900-01-01 or something) if date parsing fails for any reason

I'll think on it and push up a fix later tonight.

Does C# offer any way to take a month abbreviation? Jan Feb Mar Apr etc.?
On Tue, Oct 2, 2018 at 5:06 PM Josh Darnell<EMAIL_ADDRESS>wrote:

Thanks, Erik! There is a typo in the source data
https://support.microsoft.com/en-us/help/321185/how-to-determine-the-version-edition-and-update-level-of-sql-server-an
:
Septmeber 20, 2018
I'm on the fence about how to fix this in the meantime. I'm thinking
either:

add temporary code to handle that specific typo, or
put some kind of default date (1900-01-01 or something) if date
parsing fails for any reason

I'll think on it and push up a fix later tonight.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/jadarnel27/SqlServerVersionScript/issues/9#issuecomment-426430352,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALDbD6c3CY0QTrIL68aq3gpEk0E9zBORks5ug9VKgaJpZM4XEF9C
.

--
Erik Darling
Consultant
Brent Ozar Unlimited http://www.brentozar.com/

It does!  Good thought, that would be more resilient to typos at the end of the word at least haha.

I created a fix/workaround (see #10)


extrudeRotate behavior is unintuitive

Discussed in https://github.com/jscad/OpenJSCAD.org/discussions/1229
Originally posted by achirita April 11, 2023
I recently had to use the extrudeRotate function and noticed that it's behavior is not that intuitive.
I thought I would be able to specify the axis around which the 2D geometry is being rotated in order to obtain the 3D geometry, but noticed that's not the case.
What's even stranger is that if I have a 2D geometry in the XY plane and I use extrudeRotate on it, it gets rotated around the Z axis, which make little sense to me.
It's like the geometry is first rotated around the X axis 90 degrees and then the extrudeRotate operation is performed.
Any thought on this one?

As mentioned, enhancing extrudeRotate() to use any axis X/Y/Z would be a nice enhancement. The default would be extruding 2D geometry from X/Y plane about X-axis, supporting 2D geometry with positive points.
NOTE: This is a breaking change.

@achirita Are you interested in rewriting extrudeRotate() to support X/Y/Z axis rotations? Of course this would go into V3, which is moving along nicely now.


Issue #74 follow up messages

Hey @schneidmaster !  For issue #74.
So even w/ StackOver Flow I could not find out why the captcha was blacked out, but I am hoping what I have added to the  app/views/repositories/submitted.erb does work.
If the code does not work, please do let me know and I will try to fix it.
-Thank you.

Looks pretty good, a couple of comments:

Could you revert the schema changes, they don't seem to do anything (other than that your schema was probably generated from a newer version of Rails) and I'd prefer to keep the PR to one issue at a time
I think we should have this disabled by default and enabled via a configuration option. Currently, all of the copy on the site is either user-configurable or draws from the locales -- a few users have submitted translations. Obviously I don't know how to translate the new copy from English, but for their setups, I don't want to start displaying some non-translated English by default.
Finally, should add a test here for the new code.

@schneidmaster Cool!
Just a quick question, what do you mean by this
I think we should have this disabled by default and enabled via a configuration option. Currently, all of the copy on the site is either user-configurable or draws from the locales -- a few users have submitted translations. Obviously I don't know how to translate the new copy from English, but for their setups, I don't want to start displaying some non-translated English by default.

-Thank you.
Also I will revert the schema to how it was before.

I think that by default, we should not show the issue link, and add a configuration option to the Repository model to allow users to turn on the issue link via a checkbox. Locales are something used by Rails to support translations of text in the application -- currently, all of the text in the app either uses locales (with some users using French and Polish) or is user-configurable (i.e. they type what they want in a form). So if we enable the issue link by default, users that are expecting the site to currently all be in French or Polish would suddenly see some English showing up when issues are submitted. Making it opt-in helps with that since we don't break current issue pages.
You should look in the spec/features folder for examples of existing feature tests.

Oh okay, I get what you are saying. So do you want me to take out the issue link?
But in the meantime I will revert the schema and write a test for this feature.

Hey @schneidmaster is there a rails command to revert the schema back to how it was originally?
-THank you.

@schneidmaster Hey any update on this?

@hd719 your test command is incorrect -- you need to be in the project root and run rspec spec/features/repositories_feature_spec.rb

@schneidmaster Hey so I am having trouble with writing out the tests, I understand the test should go under describe submit issue, but where it would it go exactly?

You can't do expect_to visit ... -- visit is a command that tells Capybara to visit the provided URL. If you're trying to test that the page is on a particular URL you're looking for expect(page).to have_current_path(whatever_path)

Hey @schneidmaster I added the new path that test's for the here button that should link to the owners repository issue, but for some reason it is not passing.

Thank you.

Hey @schneidmaster sorry for the bother, but any update with this I would really like to get this PR merged soon.
I am currently in a coding bootcamp and we have to contribute to a set number of repos. and this one is currently on my list.
P.S. By the way thank you all the help very much appreciated.

Hey @hd719. Looks like this project is actually on an older version of Capybara, if you upgrade Capybara to >= 2.5 that syntax should work.
As I said above, we'll also need to add a configuration option to the repository itself, to make this link opt-in for non-English users.

@schneidmaster Alright sounds good! I am going to try and add a configuration option so the link would work for non-English users.
Real quick in order for me to do this, where should I start? Any advice would be appreciated.

Thanks again bro!

allow_issue_title is a pretty good example -- it is a configuration option that allows users to set the issue title in GitHub, while your configuration option will be to show this link when the issue is submitted. Look at the files from this search to get an idea of where your option needs to be added.

Closing this PR for now since it seems to have gone stale. Feel free to open a new PR if you decide to take this feature back up.


rebase: update vault/api to v1.1.1

Update to the most current vault/api version.

Show available bot commands
These commands are normally not required, but in case of issues, leave any of
the following bot commands in an otherwise empty comment in this PR:

/retest ci/centos/<job-name>: retest the <job-name> after unrelated
failure (please report the failure too!)
/retest all: run this in case the CentOS CI failed to start/report any test
progress or results

/retest ci/centos/mini-e2e-helm/k8s-1.20

/retest ci/centos/mini-e2e-helm/k8s-1.20

Failed with #2264 , see logs

/test ci/centos/k8s-e2e-external-storage/1.22


XD-3560: Better display array defaults in documentation

LGTM, also verified generating doc. Squashed, rebased and merged as f3535af68722fda31945de76cdff147d8512e32c