Add Alexa.ChannelController api function. Add StepSpeaker volume step functionality

Added missing Alexa.ChannelController functions.  Specifically ChangeChannel and SkipChannel commands.  These functions will call the play_media function in a media_player app if it has the capability published and pass on the channel# or channel name.  The selected media player can then use this to select the channel on the device it is associated to.
Modified the existing Alexa.StepSpeaker Setvolume function to actually do a stepped volume change using the steps sent by Alexa. The Alexa default step of 10 for a simple volume up/down can be changed via an exposed media_player attribute called volume_step_default.  A better value would be 5.  Any other value then default will be sent as sequential volume  up /down to the media_player.
Related issue (if applicable): fixes #
No extra configuration needed for the Alexa component.  These changes has been tested on a live system.

Good idea. I will do that.  Still working on the formatting . You guys are
strict ! lol
Alain
On Sun, Oct 13, 2019 at 3:11 PM ochlocracy<EMAIL_ADDRESS>wrote:

@ochlocracy commented on this pull request.
In homeassistant/components/alexa/handlers.py
https://github.com/home-assistant/home-assistant/pull/27605#discussion_r334291752
:

if 'number' in directive.payload['channel'].keys():

   channel = directive.payload['channel']['number']

elif 'callSign' in directive.payload['channel'].keys():

   channel = directive.payload['channel']['callSign']

elif 'name' in directive.payload['channelMetadata'].keys():

   channel = directive.payload['channelMetadata']['name']

According the Alexa API channel.number, channelMetadata.name,
channel.callSign, channel.affiliateCallSign or channel.uri will be
provided in the directive. Is it possible to handle the
channel.affiliateCallSign and channel.uri too?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/27605?email_source=notifications&email_token=ABW4E7LJDUEUZXNJVCQOAS3QONXGBA5CNFSM4JAH6NTKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCHY5O6Y#pullrequestreview-301062011,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABW4E7JQD6MWRMNGX655RYLQONXGBANCNFSM4JAH6NTA
.

Yes, I saw that in the api docs. Worked without it but best to add the
context section. I will do that as well.
On Sun, Oct 13, 2019 at 3:23 PM ochlocracy<EMAIL_ADDRESS>wrote:

@ochlocracy commented on this pull request.
In homeassistant/components/alexa/handlers.py
https://github.com/home-assistant/home-assistant/pull/27605#discussion_r334292228
:

data = {

   ATTR_ENTITY_ID: entity.entity_id

}

if channel > 0:

   await hass.services.async_call(

       entity.domain, SERVICE_MEDIA_NEXT_TRACK,

       data, blocking=False, context=context)

if channel < 0:

   await hass.services.async_call(

       entity.domain, SERVICE_MEDIA_PREVIOUS_TRACK,

       data, blocking=False, context=context)

return directive.response()

⬇ Suggested change

return directive.response()

response = directive.response()

response.add_context_property(

   {

       "namespace": "Alexa.ChannelController",

       "name": "channel",

       "value": {

         "number": "1234",

         "callSign": "callsign1",

         "affiliateCallSign": "callsign2"

       }

   )

   return response

According the the Alexa API:
You must send an Response event if a request to change or skip channels
was successful. The response should include a context object that reports
the channel after the request completes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/27605?email_source=notifications&email_token=ABW4E7MX7SMMK2CQCRQXH5DQONYRJA5CNFSM4JAH6NTKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCHY5SMY#pullrequestreview-301062451,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABW4E7IC2BOBD2HYGSCW343QONYRJANCNFSM4JAH6NTA
.

The only issue is that channel state is not a given when using skipchannel
as there is no feedback on knowing the current channel and therefore the
returned context will most likely not have the actual tuned channel.  In
this case, a fixed value of 0000 or 9999 perhaps will be given.  With the
changechannel command , it's easy, just return the value received on the
original request. Will need to try and see the results.
On Sun, Oct 13, 2019 at 3:25 PM Alain Turbide<EMAIL_ADDRESS>wrote:

Yes, I saw that in the api docs. Worked without it but best to add the
context section. I will do that as well.
On Sun, Oct 13, 2019 at 3:23 PM ochlocracy<EMAIL_ADDRESS>wrote:

@ochlocracy commented on this pull request.
In homeassistant/components/alexa/handlers.py
https://github.com/home-assistant/home-assistant/pull/27605#discussion_r334292228
:

data = {

   ATTR_ENTITY_ID: entity.entity_id

}

if channel > 0:

   await hass.services.async_call(

       entity.domain, SERVICE_MEDIA_NEXT_TRACK,

       data, blocking=False, context=context)

if channel < 0:

   await hass.services.async_call(

       entity.domain, SERVICE_MEDIA_PREVIOUS_TRACK,

       data, blocking=False, context=context)

return directive.response()

⬇ Suggested change

return directive.response()

response = directive.response()

response.add_context_property(

   {

       "namespace": "Alexa.ChannelController",

       "name": "channel",

       "value": {

         "number": "1234",

         "callSign": "callsign1",

         "affiliateCallSign": "callsign2"

       }

   )

   return response

According the the Alexa API:
You must send an Response event if a request to change or skip channels
was successful. The response should include a context object that reports
the channel after the request completes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/27605?email_source=notifications&email_token=ABW4E7MX7SMMK2CQCRQXH5DQONYRJA5CNFSM4JAH6NTKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCHY5SMY#pullrequestreview-301062451,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABW4E7IC2BOBD2HYGSCW343QONYRJANCNFSM4JAH6NTA
.

What do you think of also implementing the step portion in the skip
channel.  For now, it treats it as 1.  Adding a for loop wil allow the user
to skip however many channels they require, just like the StepSpeaker
function.
Easy to do.
On Sun, Oct 13, 2019 at 3:34 PM Alain Turbide<EMAIL_ADDRESS>wrote:

The only issue is that channel state is not a given when using skipchannel
as there is no feedback on knowing the current channel and therefore the
returned context will most likely not have the actual tuned channel.  In
this case, a fixed value of 0000 or 9999 perhaps will be given.  With the
changechannel command , it's easy, just return the value received on the
original request. Will need to try and see the results.
On Sun, Oct 13, 2019 at 3:25 PM Alain Turbide<EMAIL_ADDRESS>wrote:

Yes, I saw that in the api docs. Worked without it but best to add the
context section. I will do that as well.
On Sun, Oct 13, 2019 at 3:23 PM ochlocracy<EMAIL_ADDRESS>wrote:

@ochlocracy commented on this pull request.
In homeassistant/components/alexa/handlers.py
https://github.com/home-assistant/home-assistant/pull/27605#discussion_r334292228
:

data = {

   ATTR_ENTITY_ID: entity.entity_id

}

if channel > 0:

   await hass.services.async_call(

       entity.domain, SERVICE_MEDIA_NEXT_TRACK,

       data, blocking=False, context=context)

if channel < 0:

   await hass.services.async_call(

       entity.domain, SERVICE_MEDIA_PREVIOUS_TRACK,

       data, blocking=False, context=context)

return directive.response()

⬇ Suggested change

return directive.response()

response = directive.response()

response.add_context_property(

   {

       "namespace": "Alexa.ChannelController",

       "name": "channel",

       "value": {

         "number": "1234",

         "callSign": "callsign1",

         "affiliateCallSign": "callsign2"

       }

   )

   return response

According the the Alexa API:
You must send an Response event if a request to change or skip channels
was successful. The response should include a context object that reports
the channel after the request completes.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/27605?email_source=notifications&email_token=ABW4E7MX7SMMK2CQCRQXH5DQONYRJA5CNFSM4JAH6NTKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCHY5SMY#pullrequestreview-301062451,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABW4E7IC2BOBD2HYGSCW343QONYRJANCNFSM4JAH6NTA
.

@Dilbert66

What do you think of also implementing the step portion in the skip channel. For now, it treats it as 1. Adding a for loop wil allow the user to skip however many channels they require, just like the StepSpeaker function. Easy to do.

I'm not versed enough in the media_player component to know how to best handle that. But, if the user asks to channel up (skip) 5 channels the handler should make that request to the media_player service, not just the single next as you have it.
Regarding everything else, I've been working on adding other Alexa Controllers, so just trying to help you out with the simple stuff before the HA reviewers get to it.

@Dilbert66 and @ochlocracy sorry disturbing you.
Few days ago I made a pull request that implements che ChannelController interface that has not yet been reviewed.
I choosed to define 3 new services at media player level (next/prev_channel and channel_set).
Regards,
Paolo
PS: @ochlocracy... Here you are 2 different approach to the same problem... I think it's up to you to choose one of the two.

Hi Paolo I'll have a look at your pull request. Perhaps it will meet my
needs as well. I don't mind removing my request as long as we end up with a
good versatile solution
On Sun., Oct. 13, 2019, 5:02 p.m. Paolo Tuninetto<EMAIL_ADDRESS>wrote:

@Dilbert66 https://github.com/Dilbert66 and @ochlocracy
https://github.com/ochlocracy sorry disturbing you.
Few days ago I made a pull request that implements che ChannelController
interface that has not yet been reviewed.
I choosed to define 3 new services at media player level
(next/prev_channel and channel_set).
Regards,
Paolo
PS: @ochlocracy https://github.com/ochlocracy... Here you are 2
different approach to the same problem... I think it's up to you to choose
one of the two.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/27605?email_source=notifications&email_token=ABW4E7OYOXOGILLSR37ZUQ3QOOEGTA5CNFSM4JAH6NTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBDAIDQ#issuecomment-541459470,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABW4E7MJ67ONP5GFG2GK7SLQOOEGTANCNFSM4JAH6NTA
.

Hi Paolo, I had a quick look at your implementation and it looks good.  The
main difference with your changes are that they require other changes to
the core media player, and my implementation is using the current available
function play_media for channel change since it does have a "channel"
option.  The skip channel is done via nexttrack which I agree is not
technically a channel function but depending on how the media_player is
configured will work fine.   Your approach is perhaps the more "correct"
way as it adds TV specific changes to the media player. Mine is a bit less
intrusive.   This is really a decision by the main developers as to how
they want to enhance the media player's versatility.   If they want to add
the extra features to the media player, I'd be happy with that as well.  I
still need to correct some changes on mine so I will wait till yours is
fully reviewed before completing the pull request on my end.     If I may
offer a suggestion , you might also want to enhance the skipchannel
function to allow multiple channel skip's since that capability is offered
in the alexa API. I don't have that now but intend on adding it.
Regards, Alain
On Sun, Oct 13, 2019 at 5:02 PM Paolo Tuninetto<EMAIL_ADDRESS>wrote:

@Dilbert66 https://github.com/Dilbert66 and @ochlocracy
https://github.com/ochlocracy sorry disturbing you.
Few days ago I made a pull request that implements che ChannelController
interface that has not yet been reviewed.
I choosed to define 3 new services at media player level
(next/prev_channel and channel_set).
Regards,
Paolo
PS: @ochlocracy https://github.com/ochlocracy... Here you are 2
different approach to the same problem... I think it's up to you to choose
one of the two.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/27605?email_source=notifications&email_token=ABW4E7OYOXOGILLSR37ZUQ3QOOEGTA5CNFSM4JAH6NTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBDAIDQ#issuecomment-541459470,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABW4E7MJ67ONP5GFG2GK7SLQOOEGTANCNFSM4JAH6NTA
.

Currently i'm using a custom media_player called (
https://community.home-assistant.io/t/smartir-control-your-climate-tv-and-fan-devices-via-ir-rf-controllers/
https://community.home-assistant.io/t/smartir-control-your-climate-tv-and-fan-devices-via-ir-rf-controllers/100798/526)
SmartIR  that uses a broadlink IR device to control a tv cable box.  It
basically uses all standard media_player functions.  The channel change
piece is extremely handy to control my tv as it handles all volume,
channel, play/pause (PVR),etc.
From what I can see, the media_play function being available for channel
changes should not be an issue as long as the media_player handles the
function correctly and validates the media type field being sent before
processing the request.  The type being used is 'channel' and is part of
the allowed data types.  I can't see any other way without adding new
SUPPORT_xxx flags to specify tv functions only I was trying to avoid doing
too many changes to the media_player model.  I suspect the media_player
entity model is due for some new capabilities enhancements.
On Sun, Oct 13, 2019 at 4:25 PM ochlocracy<EMAIL_ADDRESS>wrote:

@ochlocracy commented on this pull request.
In homeassistant/components/alexa/entities.py
https://github.com/home-assistant/home-assistant/pull/27605#discussion_r334295090
:

   if supported & media_player.const.SUPPORT_PLAY_MEDIA:

       yield AlexaChannelController(self.entity)

Out of curiosity, what integration are you using/testing this with?
Unfortunately, it looks like there need to be some additions to the
media_player entity model to determine support for channel equipped media
players, otherwise there is a potential to expose this controller to all
media_player entities that support SUPPORT_PLAY_MEDIA.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/27605?email_source=notifications&email_token=ABW4E7P7VXJY7YLLCDIUHLDQON737A5CNFSM4JAH6NTKYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCHY6ITQ#pullrequestreview-301065294,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABW4E7M6CYJMA34AXMPXAZLQON737ANCNFSM4JAH6NTA
.

Hi Alain, as I said, we simply had different  approach to the same problem. Both with pros and cons.
Let's wait until they choose

Hello @Dilbert66,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

25c81fbd0811689a369d939ff6f42e7e447d6949 - This commit has something that looks like an email address (alt@ha.hass99.duckdns.org). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

Hello @Dilbert66,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

25c81fbd0811689a369d939ff6f42e7e447d6949 - This commit has something that looks like an email address (alt@ha.hass99.duckdns.org). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

Hello @Dilbert66,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

25c81fbd0811689a369d939ff6f42e7e447d6949 - This commit has something that looks like an email address (alt@ha.hass99.duckdns.org). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

Hello @Dilbert66,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

25c81fbd0811689a369d939ff6f42e7e447d6949 - This commit has something that looks like an email address (alt@ha.hass99.duckdns.org). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

Hello @Dilbert66,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

25c81fbd0811689a369d939ff6f42e7e447d6949 - This commit has something that looks like an email address (alt@ha.hass99.duckdns.org). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

Hello @Dilbert66,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

25c81fbd0811689a369d939ff6f42e7e447d6949 - This commit has something that looks like an email address (alt@ha.hass99.duckdns.org). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

Hello @Dilbert66,
When attempting to inspect the commits of your pull request for CLA signature status among all authors we encountered commit(s) which were not linked to a GitHub account, thus not allowing us to determine their status(es).
The commits that are missing a linked GitHub account are the following:

25c81fbd0811689a369d939ff6f42e7e447d6949 - This commit has something that looks like an email address (alt@ha.hass99.duckdns.org). Maybe try linking that to GitHub?.

Unfortunately, we are unable to accept this pull request until this situation is corrected.
Here are your options:

If you had an email address set for the commit that simply wasn't linked to your GitHub account you can link that email now and it will retroactively apply to your commits. The simplest way to do this is to click the link to one of the above commits and look for a blue question mark in a blue circle in the top left. Hovering over that bubble will show you what email address you used. Clicking on that button will take you to your email address settings on GitHub. Just add the email address on that page and you're all set. GitHub has more information about this option in their help center.

If you didn't use an email address at all, it was an invalid email, or it's one you can't link to your GitHub, you will need to change the authorship information of the commit and your global Git settings so this doesn't happen again going forward. GitHub provides some great instructions on how to change your authorship information in their help center.

If you only made a single commit you should be able to rungit commit --amend --author="Author Name<EMAIL_ADDRESS>
(substituting Author Name and<EMAIL_ADDRESS>for your actual information) to set the authorship information.
If you made more than one commit and the commit with the missing authorship information is not the most recent one you have two options:

You can re-create all commits missing authorship information. This is going to be the easiest solution for developers that aren't extremely confident in their Git and command line skills.
You can use this script that GitHub provides to rewrite history. Please note: this should be used only if you are very confident in your abilities and understand its impacts.

Whichever method you choose, I will come by to re-check the pull request once you push the fixes to this branch.

We apologize for this inconvenience, especially since it usually bites new contributors to Home Assistant. We hope you understand the need for us to protect ourselves and the great community we all have built legally. The best thing to come out of this is that you only need to fix this once and it benefits the entire Home Assistant and GitHub community.
Thanks, I look forward to checking this PR again soon! :heart:

I'm closing this pull request as i need to rebuild my forked copy after having issues with my devevlopment environment.  Will re pull once all rectified.


Need detailed error information on failed POST/PUT requests

Will add more detailed error handling that returns additional details on failed requests

This will be fixed in jobbergateapi2


Can't pipe Get-PlasterTemplate into Invoke-Plaster

On my first attempt to use Plaster I tried
Get-PlasterTemplate | select -Skip 1 | Invoke-Plaster -DestinationPath r:\temp

And I was prompted for the TemplatePath anyway which was very odd. I reviewed the repo and saw the TemplatePath parameter was not marked with ValueFromPipelineByPropertyName=$true. That cleared up why it did not work but I felt it should so I cloned the repo to start to add it.
That is when I realized all the code is in the begin block and pipeline parameters are not passed to begin only process and end. When I added close brace on line 157 and process { on line 159 everything now works as expected and you can pipe Get-PlasterTemplate into Invoke-Plaster.
I had never seen a method that only used begin so instead of submitting a pull request I figured I should log an issue so someone could explain to me why this was done and if what I have done is a safe change.

AFAIK, there wasn't a reason for it and a PR would be awesome fixing this!
Just want to hear what @rkeithhill has to say first

Sweet I will submit my change for review.

The bulk of the "shared functions" are in the begin block.  They are defined there and used later in the end block.  There is some imperative code in begin that could be moved to a process block.  Just keep in mind that pipelining was not the primary scenario for Plaster.  What we wanted to make sure that worked (just like Yeoman) is that the user could specify a template path, Plaster would read that and then prompt for the various bits of info the template author needs from the user.  But we also wanted to support fully automated scenarios where the user could supply all the required template info via dynamic parameters.  If we support pipeline input, then we must make sure those two scenarios work.  I feel good about the first one (interactive prompting). I'm not as sure about the second scenario involving dynamic parameters.

OK, I just submitted a PR with the change for review. I have been using my version and everything works as expected. I only wanted to pipe in the Template path not all the prompting for input (which still happens).

But does the dynamic parameter support still work e.g.:
Get-PlasterTemplate | select -Skip 1 | Invoke-Plaster -DestinationPath r:\temp -Author Jon -Version 0.1.0 -Editor VSCode

Note: Use whatever parameter names are defined in the template you're using.


cv2pdb can't find the debug info of mscoff executables

I've been unable to debug my mscoff-built project, so I did some experimentation with a dummy project to see what was failing here.
I just tried all 6 permutations of [ldc2/dmd -m32mscoff] and [-g/-gc/no debug info], and also one control run without -m32mscoff.
Comparing the binary output between the builds, both compilers are definitely producing extra output when debug info is enabled (I figured one possibility was that the compilers simply didn't support embedding debug info into 32-bit mscoff but it seems that they do), but cv2pdb always reports no debug info found.
E:\code\dlang\temp\mscoff_tests>cv2pdb.exe coff_test-debugInfoC.exe coff_test-debugInfoC.pdb.exe coff_test-debugInfoC.exe: no codeview debug entries found
Is mscoff unsupported? : 0

PS: Thanks for maintaining this absolutely necessary D utility.

Fortunately, when I'm on Windows I've not had to debug in anything other than full IDE's. Nonetheless, I just tried Windbg to resolve this situation. The Windbg bundled with DMD 2.070.2 similarly reports No Symbolic Info for Debugee when stepping into the 32-bit COFF image that DMD was instructed to embed C-style debug info into (via -gc).
Any idea what's going wrong here?

If you build with dmd -m32mscoff or dmd -m64 or with a recent version of ldc, the generated object files contain debug info in a format that allows the MS linker to generate an appropriate PDB file that should work with standard debuggers. So you don't need to run cv2pdb on these executables, it is used to convert debug information generated with dmd -m32.
There are a few issues, though:

ldc only emits line number info, no debug info to inspect variables. This is being worked on by the LLVM people.
with dmd generated debug info type names containing '.' confuse the Visual Studio debugger, so option -gc makes dmd replace it with '@'. This is not necessary when using Visual D and the mago debug engine.

The Windbg bundled with DMD 2.070.2

IMO the version of windbg distributed with dmd must be considered a joke.

Ah! Sorry, executable formats are one of my happily accepted blackboxes ;]
So I hadn't recognized that this would be redundant.
Soon enough I'll build up enough willpower to try navigating the D obstacle course again, confirm what you explained and close out this issue from your tracker. (I hope it doesn't bother you if I leave this open in the meantime.)
sighs I must admit I'm losing my steam, though. Unlike in my earlier years, I don't have the same patience anymore. And despite the 2.x.y versioning milestone, D's proving to be incredibly rough around the edges.
I'll get back to you soon.

There are a few issues, though:

ldc only emits line number info, no debug info to inspect variables. This is being worked on by the LLVM people.

Well, if it consistently emits correct context & line number info, that's would at least be something. So far none of the solutions I've tried are even close to being dependably usable. (Is the current lack of non-buggy debugging just a Windows situation at the moment, AFAYK?)

with dmd generated debug info type names containing '.' confuse the Visual Studio debugger, so option -gc makes dmd replace it with '@'. This is not necessary when using Visual D and the mago debug engine.

Wait, is Mago supposed to be working? O_O It never has— not from the beginning when I installed VisualD a month or two ago— so, given the disclaimers on the VD page, its inheritance into VD from a dead project, and the seemingly obvious nature of how it doesn't work, I assumed it was simply known to be aged and no longer working. If it's actually supposed to be working, shoulders sagging I suppose that's another bug I'll have to get around to filing. sighs Although, there's really nothing to file. It just flat out never never kicks in and starts recognizing any debug info-- not even with an untinkered-with default VD console-mode DMD "Hello world" project. (Sorry, the nature of it was so obvious, it seemed impossible that it was supposed to be working.)

IMO the version of windbg distributed with dmd must be considered a joke.

Oh? Thanks for mentioning this. IIRC, the dlang.org page on debugging warned that not using the version bundled with DMD might not work, and also implied Ddbg was no longer working, so I would never have thought to look for a different version.
I've now on the current MS release. Indeed, it's less ancient-looking and cobbled-together as that old version. Is there anything missing from it, out-of-the-box, WRT to D-compatibility, that the bundled version has?
Argh, by know I've written enough on all the satellite issues, there's not time to report on what happened when trying your suggestion. Work to do.
sighs I'll be back.

Meh. The previous post lacks context without what I intended to write. So, a quasi-quick summary...

The Windbg bundled with DMD 2.070.2 similarly reports No Symbolic Info for Debugee when stepping into the 32-bit COFF image that DMD was instructed to embed C-style debug info into (via -gc).
Whatever it was, I got the dummy project to get its symbols recognized by the newly installed Windbg. (At this point I don't recall any other steps I might have gone through, so I assume it was just the outdated Windbg to blame).
However the real project still wasn't getting recognized. In summary, fast-forward through the search for differences and it seems that no longer including the stack size specification (/STACK:8388608) in the flags passed to the linker finally enables the symbols to get recognized.
But... the context info (what function scope we're in) & line number info is wrong, requiring using the disassembly view anyway (but at least with proper symbol names embedded into the view).
If I had a dime for every workaround...
Lightning round of satellite issues that swallowed my time & energy but that I can't elaborate on right now:

DMD produces an internal compiler error for m32mscoff if you don't pass an output file name (ie. when in multiobj mode).
I don't remember the rest at the moment... it's a minefield.

Anyway, this clearly beyond the scope of cv2pdb now.. Thanks. Closing the issue and working around/battling against D some more when I have time to.
Thank for you for your tireless contributions to the community.
-C.

Sorry to hear you had such a bad debugger experience. It does work for me reasonably well (including mago), but I guess I'm just used to the quirks.

it seems that no longer including the stack size specification (/STACK:8388608) in the flags passed to the linker finally enabled the symbols to get recognized. Any insights?

Never heard this problem. If you use dmd for linking, enabling verbose compilation shows the linker command line, maybe there is something fishy about it. In Visual D, you find it in the build batches in the output direcotry.

But... the context info (what function scope we're in) & line number info is wrong for parts of code I'm interested in debugging, requiring using the disassembly view anyway (but at least with proper symbol names embedded into the view). Any insights on this?

That's something I can confirm: line numbers are sometimes lost (more often in templated code AFAICT), with LDC making it worse because it creates bad entries that are more confusing than dmd's omissions. There are already bugzilla entries for this, but unfortunately, reducing the code to manageable and debuggable size often makes the problem disappear.

Sorry to hear you had such a bad debugger experience.

Thanks. And message tone can often get misinterpreted on the internet so hopefully you know that I'm not sarcastic when I thank you for you contributions...
I've been privately hacking on the internals of several core D projects in the past month during my foray into this wonderful but not-yet-ready-for-primetime language, and the prior pull requests and the like all tell the same story: D needs more people like you.
Your contributions in both code and in advice towards making the experience on Windows (the predominant platform, in case people have forgotten) work properly are crucial.
D needs a whole lot more if it is ever to be considered release quality —and thus acceptably-usable for people that aren't interested in having to muck about (IE. the rest of the programming audience that it's missing)— but it won't get there if it doesn't receive contributions like yours.
So thanks.

It does work for me reasonably well (including mago)

You have me curious now. I’ll step over to the mago repository/issue tracker when I get a chance.
Take care,
C.


Update EntityDescription.ts

Removes assumption that the infobox always has the bodyless class.
From looking at the infobox behavior it looks like the bodyless class isn't always present when you click different entities. Removing it fixed the issues detailed in https://github.com/reearth/resium/issues/628
Tested both on my local environment using Resium as well as the story noted in the issue that exhibited similar behavior.
closes #628

Updated branch to be on latest, is this able to get merged? While we have a workaround it's not ideal.
Thanks!

@mfarmer-ara  We've released your change in v1.18.0. Thank you!


Maybe we can handle the pictures in pdf more easily

Can you enhance a conversion feature? Perhaps we can provide a downloadable zip file containing a markdown file and an images folder, with the markdown file referencing the images in the folder.
I would be extremely grateful if you could develop this feature.

We can use pdfjs-srverless to work in nodejs nd polyfill canvas with base64 string exporter https://github.com/unjs/unpdf/issues/20


Configure analyzer to enable/disable certain lints

It looks like it's almost possible, but not completely, to configure which lints are applied per project, via the .analysis_options file
Let's make it possible and awesome!

Let's make it possible and awesome!

Done.
Bonus points for validation of known lint rules.

:+1:


Doesn't work correctly with async_trait

I'm implementing a Clean Architecture, where I've got a number of Traits that represent my Use Cases, and then a single Struct that implements these. That works great, and means that I've got good structure to my code.
However, testing it has been awkward in Rust. Faux seems to be ideal because I can mock out the structs and not need to have generics everywhere, but it doesn't seem to work with async_trait. By the errors, I'm needing to return a Pin<Box<Future<Output = XXX>> from my mock instead of just an XXX, but actually doing that is not always trivial.

By async-trait do you mean: https://github.com/dtolnay/async-trait
Could you please provide an example of the code you are attempting to write?
Does the error occurs during the expansion of #[faux::methods] or when attempting to mock the method with when!(...).then(...)?

I do mean that crate, yes.
I'll try and put together a simple example of the problem, but basically:
In my test, I have the line:
    faux::when!(player_service.register_player).safe_then(|_| Err(PlayerRegistrationError::UnknownError));

The struct player_service is defined as:
/// Use case for registering players
#[async_trait]
pub trait PlayerRegistration {
  /// Attempt to register a player account, or return the existing one if it's already registered
  async fn register_player(&self, details: Registration)
    -> Result<Player, PlayerRegistrationError>;
}

/// The Player Service to interact with players
#[cfg_attr(test, faux::create)]
pub struct PlayerService {
  pub(super) repository: PlayerRepository,
}

#[cfg_attr(test, faux::methods)]
impl PlayerService {
  /// Create a new Player Service
  pub fn new(repository: PlayerRepository) -> Self {
    Self { repository }
  }
}

#[async_trait]
#[cfg_attr(test, faux::methods)]
impl PlayerRegistration for PlayerService {
  /// Attempt to register a player account, or return the existing one if it's already registered
  async fn register_player(
    &self,
    details: Registration,
  ) -> Result<Player, PlayerRegistrationError> {
    log::info!("Registering player: {:?}", details);
    todo!()
  }
}

The idea being that PlayerRegistration is a "Use Case" as defined by the Clean Architecture, and so is a trait. This needs to be async because it's ultimately working in terms of bb8, which is itself all async.
However, building the above gives me:
error[E0308]: mismatched types
   --> src/authentication/google/provider.rs:316:63
    |
316 |     faux::when!(player_service.register_player).safe_then(|_| Err(PlayerRegistrationError::UnknownError));
    |                                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |                                                               |
    |                                                               expected struct `std::pin::Pin`, found enum `std::result::Result`
    |                                                               help: you need to pin and box this expression: `Box::pin(Err(PlayerRegistrationError::UnknownError))`
    |
    = note: expected struct `std::pin::Pin<std::boxed::Box<dyn static_assertions::core::future::future::Future<Output = std::result::Result<entity::entity::Entity<players::models::player_id::PlayerId, players::models::player::PlayerData>, players::usecases::registration::PlayerRegistrationError>> + std::marker::Send>>`
                 found enum `std::result::Result<_, players::usecases::registration::PlayerRegistrationError>`

I think the trick to get this to work is to flip proc macro order. If you change put #[cfg_attr(test, faux::methods)] above #[async_trait] it seems to work.
I wrote a little short snippet: https://github.com/nrxus/faux-playground/blob/master/src/lib.rs

I am honestly surprised that it "just" works to be honest. I will write down below some implementation reasons why it works just to note them down, but they are implementation detail-y so no need for anyone to read (:
faux supports inherent async fns through a fairly ~hacky~ simple change: call .await when proxying to the real method, otherwise behave as normal. faux deliberately makes it so that when! behaves as if it was NOT async, thus not needing any futures or pins or what not.
If faux gets to do it's expansion before async-trait's macro then it still thinks that the function is just a normal async fn and expands as usual. The "real" method is copied with all of its original attributes (i.e., proc macros). async-trait then does it's magic on the real method, but faux does not really care because at the end of the day it can call .await on it so it's fine. async-trait then ALSO does its magic on the morphed method that faux expanded to, changing the signature to no longer be async, but since faux already run then it all goes smooth.
I am honestly SHOCKED but pleased that this works, it validated my original assumption that I should keep all of the attributes and whatnot on both the original and the morphed method :grinning:

Interesting. That's my Java developer showing through - it never even occurred to me that the order of those would have any impact at all! (I still don't fully understand why it does, but it's good enough for now :) )

I wrote a bit about it in the README that will hopefully help explain it a bit better. Let me know if something still doesn't quite make sense, it definitely needs a couple of edits for clarity but i was unsure exactly how.
I am closing this issue, however, since it does not seem to be an issue that faux could address other than better documentation which the new README section is trying to do.


chore: add docker push workflow

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 60.86%. Comparing base (56c57d6) to head (d179709).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##           master       #4      +/-   ##
==========================================
+ Coverage   57.73%   60.86%   +3.13%
==========================================
  Files           9        9
  Lines         168      138      -30
==========================================
- Hits           97       84      -13
+ Misses         62       45      -17
  Partials        9        9

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


Using &. returns  E: unexpected token error

Since target ruby version is ruby 2.2

Avoid the issue by overriding the setting.


refactor(FQDN): further more refator on idl/dsn.layer2.thrift

This is a further refactor on idl/dsn.layer2.thrift, the main effects are on
partition_configuration structure.
To keep compatible and support rolling update, it should be accepted that partial
servers or clients with the FQDN supporting feature and partial of them without
the feature. In this patch, macros like GET_HOST_PORT and GET_HOST_PORTS are
used in almost all places where partition_configuration objects appear. (Unit
tests don't require this because the tests must in the latest version which has
this feature).
When invoking a RPC, it's preferred to use host_port because we suppose that the
IP address is possible to be changed, but the hostname is permanent.
When received a proposol request, the optional hp_primary and hp_secondaries
will be filled by the related host_ports of the primary and secondaries and
fields. Then we can simplily deal with the logic.

Please ignore the clang-tidy warnings, because there are so many warings, it would introduce too many clang-tidy related changes as well which may cause the main changes of this pull request hard to distinguish and review.


Caching support

/feature
Is your feature request related to a problem? Please describe.
mountpoint-s3 supports caching-configuration:
https://github.com/awslabs/mountpoint-s3/blob/main/doc/CONFIGURATION.md#caching-configuration
If s3 has a lot of objects then list command could huge increase costs.
Describe the solution you'd like in detail
allow mountpoint-s3-csi-driver to use caching
I've tried enable it but is doesn't work now.

As of the v1.1.0 release for the CSI driver, caching is supported. The error you are most likely getting is that the cache directory does not exist. This is because the cache directory has to exist at the instance level (the root filesystem outside of the containers). In the current implementation, the caching directory has to be created manually, we will consider an enhancement of creating a caching directory before the mount happens.
If you are still seeing issues when the cache directory exists, please include the errors you are seeing in the driver's logs.

How do you create the cache directory? Do you have to log into the nodes manually and if so, do you just pick the node your application in question is running on?

Yes, you can SSH into your instance(s) and create the directory (you can do it on just the instance that's running the driver or on both so you know the directory exists regardless of the node it's running on). Then when you point the same directory in mountOptions, it will use that as the cache directory.


chore: release 0.0.3

:robot: I have created a release *beep* *boop*
0.0.3 (2023-02-16)
Bug Fixes

wrong export module (8ef0fc5)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/keq-request/keq-exception/releases/tag/v0.0.3 :sunflower:


Failed to load local html files in real devices

This PR is related with
kCFErrorDomainCFNetwork (error code 1) in real device but no in simulator #396

@jimerino, thanks for this PR!
Since you need a device to test this, I'd like to ask if you've had a chance to test it on an actual device yourself?

@harrisrobin you're wellcome!
I've tested it in a real device before publish the PR in my fork and works. Do you have any pre-release branch to merge the PR and test or a test in my fork is enough?

Ok, finally managed to test it on a real device. Looks good to me 👍
@Titozzz LMK if we need anything else before we can merge this :)

Thanks for testing @harrisrobin !

Is this PR published or merged into master?


missing default template/xslt files in the gem install

I'm using RVM with Ruby 2.2.0 and when I try to use the gem I get path issues along the following lines:
Zip::Error (File<EMAIL_ADDRESS>not found):
  app/controllers/welcome_controller.rb:6:in `block in index'
  app/controllers/welcome_controller.rb:5:in `index'

Looking in the gemset folder for the gem files shows they are not there either.

Looks like this got fixed in later commits.  I updated bundler to point to the master branch and it works without overriding the config.
Might be a good time to create a new version of the gem since anyone who installs v0.2.0 is going to have a bad day.

@jonknapp I'm having the same problem. After I do a gem install, the XSLT folder isn't copied over. Weirdly, the gem is still able to convert the basic HTML to a Word doc. Don't know how this is happening. How were you able to get the XSLT and template folder to get added to the gem?

:+1:

Hi, maintenance of this gem has been moved to https://github.com/karnov/htmltoword. Please try the newest version and report this issue if it still occurs


Repeated merge commands trigger confusing message and corrupt queue state

When hoff appears stuck (e.g. due to a missed webhook), a common first reflex might be to trigger hoff again with another merge command. That is not how hoff processes PRs, however, and such repeated merge commands should actually have no effect if the build is still in progress.
The initial merge would trigger a message like

Rebased as acdc1234, waiting for CI …

Then, after more PRs have queued up, but hoff appearing stuck because CI never picked up the build, someone repeats the merge command and hoff prints:

Speculatively rebased as acdc1234 behind 5 other PRs, waiting for CI …

Evidently, it didn't actually rebase the branch again, because the commit hash is still the same, despite (according to the message) there now being more PRs before it.
Interestingly, this immediately triggered the PRs queued after (which were already done on CI) to get merged, including the commit from the original stuck PR.
But since hoff never got a CI update, it was still stuck and blocking the queue. Closing and reopening took it from the queue, but the commit has already been merged to master.
So it appears that issuing a repeated merge command while hoff is already processing a PR corrupts the internal state, moving the PR to the end of the internal queue, but keeping the commit at its original place in the merge train.
Maybe the fix is as easy as rejecting any commands received while a PR is being processed.

It's been a while since I looked at Hoff but IIRC accepting merge approval commands when a merge was already approved was intended behavior  because it would let you change the approval type (merge, merge and tag, merge and deploy to X).
If you take the CI webhooks out of the picture, repeating the merge command should be safe. I've done this before locally without issues. There is only one test case (partially) covers this though:
https://github.com/channable/hoff/blob/957019c795ca8a78640498cf64f5c9b60aaf3f4f/tests/Spec.hs#L3008-L3022

So in essence, I believe re-issuing the merge command caused the approval order to desync from the commit integration history. We can either

Not set the approval order variable for a PR if it is already being integrated, but do update the merge command used itself, so we still support upgrading merges.
Ignore any merge commands received while a PR is already in the integration queue.
We can do something like retry and reissue the merge command, but remove the PR from its position in the queue and re-add it at the end. So essentially the same as close PR -> re-open PR -> issue merge command

1 and 2 don't quite solve the CI webhoook not being received problem, but they do avoid the multiple merge command issue. 3 causes new webhooks to be received so fixes it both problems, so I'll inclined to go for that. WDYT?

I think (3) has the most straightforward semantics indeed, and does what people would expect it to do.


Added go.mod

Added go.mod in order to improve compatibility with projects that use modules.

@tklauser
I hope the PR can help the project.

Sure. Thanks


Set a number of threads

Related #269
Minimum example
from optimum.intel import OVStableDiffusionPipeline

model_id = "echarlaix/stable-diffusion-v1-5-openvino"
ov_config = {"INFERENCE_NUM_THREADS": 20}
pipeline = OVStableDiffusionPipeline.from_pretrained(model_id,
        ov_config=ov_config)
prompt = "sailing ship in storm by Rembrandt"
images = pipeline(prompt).images

ov_config does not work in this case. As a result, the system still uses 10 threads in total. Is this expected? or am I using a wrong parameter?

Hi @wonkyoc, thnaks for reporting this and apologies for the delay, do you still observe this issue with the latest openvino release ?
cc @eaidova who might have some insight on this

Environment
$ optimum-cli env
- `optimum` version: 1.18.0.dev0
- `transformers` version: 4.38.2
- Platform: Linux-5.15.0-75-generic-x86_64-with-glibc2.35
- Python version: 3.10.9
- Huggingface_hub version: 0.21.4
- PyTorch version (GPU?): 1.13.1+cu117 (cuda availabe: True)
- Tensorflow version (GPU?): not installed (cuda availabe: NA)

$ pip list | grep openvino
openvino                      2024.0.0
openvino-telemetry            2023.2.1

Hi @echarlaix, thanks for getting back. I am still seeing this issue on the latest openvino. Please check the env. You can also check a piece of evidence via the below screenshot:

@wonkyoc This is probably expected behaviour. If you set INFRENCE_NUM_THREADS to 2 I expect you will see that it is being respected. OpenVINO does not allocate more threads than the number of physical cores in the system. If your system supports hyperthreading, you can add {"ENABLE_HYPER_THREADING": True} to ov_config to use 20 threads. There are pros and cons about that and I recommend checking accuracy.

This makes sense. The system uses hyperthreading. Thanks for your explanation! I am closing this issue.


[chocolatey] Ability to override version

Funny thing... Chocolatey doesn't support our version scheme:
PS D:\a\chocolatey-bucket\chocolatey-bucket> Chocolatey v0.12.0
'2.7.0.Final' is not a valid version string.
Parameter name: version

I don't see us changing our naming scheme anytime soon so I wonder if we could override the version that is injected here:
https://github.com/quarkusio/chocolatey-bucket/blob/main/quarkus/quarkus.nuspec#L8
I'll experiment but I think that's all that would be needed.
We need to be able to define it with a environment variable as we will need to script the suffix removal.
I can probably dedicate some time to get this in shape but I wanted to check if you thought it was the way to go or if there was some other options.

To get around this problem you can generate a chocolatey template
jbang jreleaser@jreleaser template -d quarkus -p chocolatey

Then edit the generated templates (probably just the nuspec template) and use any of the other name templates related to project version numbers https://jreleaser.org/guide/latest/configuration/name-templates.html#_project
you might end up with {{projectVersionMajor}}.{{projectVersionMinor}}.{{projectVersionPatch}} instead of just '{{projectVersion}}'.

The jpackage assembler lets you override the appVersion which also imposes restrictions on the format. while the proposed workaround with templates works it also makes sense to add a property to the DSL to override the version without having to use file templates.

Yeah, problem is my templates will get out of date and there's a good chance I won't follow things closely to update them regularly.
For now I ended up with this ugly thing:
https://github.com/quarkusio/chocolatey-bucket/blob/main/.github/workflows/push.yml#L11-L14
But I'll add to my todolist to allow defining a version.

https://docs.chocolatey.org/en-us/create/create-packages#package-fix-version-notation

FWIW they may accept other tags as JReleaser v1.0.0-M1 is listed https://community.chocolatey.org/packages/jreleaser/#versionhistory
I'll have to research more on version handling by chocolatey before committing to a fix.

@aalmiray any chance it could also be set via an environment variable? Because I will need to do some magic to strip the .Final suffix.

@gsmet perhaps by enabling the use of JRELEASER_CHOCOLATEY_PACKAGE_VERSION, would that be OK with you?

@gsmet but before going the route of an env var you can do the following today after this fix was merged:
jreleaser.yml
packagers:
  chocolatey:
    active: always
    packageVersion: '{{projectVersionMajor}}.{{projectVersionMinor}}.{{projectVersionPatch}}'

In other words, you don't have to pre-process the version, you can use name templates instead.

That's perfect, then, thanks!

@gsmet alright. Let me know of this option works for you (give it a try with jreleaser prepare -p chocolatey and inspect out/jreleaser/prepare/*). If it's not enough then I'll add the env var.

@aalmiray - I am getting a regression. I have defined the project "version" as "16.16.11", and it fails with the following exception. I tried defining the Chocolatey "packageVersion" as well, but it failed in the same way. Any thoughts?
jreleaser.shadow.org.jreleaser.util.JReleaserException: JReleaser has not been properly configured.
Invalid chocolatey package version 16.16.11. Follow SemVer with optional .number or .yyyyMMdd as tag

	at jreleaser.shadow.org.jreleaser.engine.context.ModelValidator.validate(ModelValidator.java:53)
	at jreleaser.shadow.org.jreleaser.workflow.WorkflowImpl.<init>(WorkflowImpl.java:42)
	at jreleaser.shadow.org.jreleaser.workflow.Workflows.fullRelease(Workflows.java:117)
	at jreleaser.shadow.org.jreleaser.cli.FullRelease.doExecute(FullRelease.java:144)
	at jreleaser.shadow.org.jreleaser.cli.AbstractModelCommand.execute(AbstractModelCommand.java:81)
	at jreleaser.shadow.org.jreleaser.cli.AbstractCommand.call(AbstractCommand.java:38)
	at jreleaser.shadow.org.jreleaser.cli.AbstractModelCommand.call(AbstractModelCommand.java:47)
	at jreleaser.shadow.org.jreleaser.cli.AbstractCommand.call(AbstractCommand.java:29)
	at jreleaser.shadow.picocli.CommandLine.executeUserObject(CommandLine.java:1953)
	at jreleaser.shadow.picocli.CommandLine.access$1300(CommandLine.java:145)
	at jreleaser.shadow.picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2358)
	at jreleaser.shadow.picocli.CommandLine$RunLast.handle(CommandLine.java:2352)
	at jreleaser.shadow.picocli.CommandLine$RunLast.handle(CommandLine.java:2314)
	at jreleaser.shadow.picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2179)
	at jreleaser.shadow.picocli.CommandLine$RunLast.execute(CommandLine.java:2316)
	at jreleaser.shadow.picocli.CommandLine.execute(CommandLine.java:2078)
	at jreleaser.shadow.org.jreleaser.cli.Main.execute(Main.java:72)
	at jreleaser.shadow.org.jreleaser.cli.Main.run(Main.java:68)
	at org.jreleaser.tool.JReleaser.main(JReleaser.java:45)

@sualeh thanks. Just pushed a fix, next early-access will be ready in half an hour. https://github.com/jreleaser/jreleaser/actions/runs/1801639117

@aalmiray - thanks - your fix worked.

@aalmiray I'm working on upgrading to M2. Are you sure you are applying the templating to the packageVersion?
I tried what you described above and I end up with:
[INFO]  JReleaser 1.0.0-M2
[INFO]  Configuring with jreleaser.yml
[INFO]    - basedir set to /data/home/gsmet/git/quarkus-release/work/quarkus/devtools/cli/distribution
[INFO]  Reading configuration
[INFO]  Loading variables from /home/gsmet/.jreleaser/config.properties
[INFO]  Validating configuration
[ERROR] == JReleaser ==
[ERROR] Invalid chocolatey package version {{projectVersionMajor}}.{{projectVersionMinor}}.{{projectVersionPatch}}. Follow SemVer with optional .number or .yyyyMMdd as tag
JReleaser has not been properly configured.
Invalid chocolatey package version {{projectVersionMajor}}.{{projectVersionMinor}}.{{projectVersionPatch}}. Follow SemVer with optional .number or .yyyyMMdd as tag

So I suspect the templating is not applied before checking the version.

I'm seeing the same error in 1.0.0-M2 and 1.0.0-SNAPSHOT at the moment.
Please use an explicit value for the time being.


Change event view text colour

Hi!
Recently I started to use this library and now I need to change the label colour of all events and I can't do this. I don't know if I'm doing something wrong or what, but I can't do it.
I think this is a good aspect to think about...

Hi @Boottexy,
EventView is a regular UIView, you can subclass it and do whatever you wish. For example, change color or the algorithm using which other supplementary colors are being calculated.
To change the algorithm, just override the following property:
  public var color = UIColor() {
    didSet {
      textView.textColor = color.darkened(amount: 0.3)
      backgroundColor = UIColor(red: color.redComponent, green: color.greenComponent, blue: color.blueComponent, alpha: 0.3)
    }
  }

Feel free to ask more questions, if there is something missing in my answer.

Hi @richardtop!
You are totally right, it works!
I don't know but if you want you can close the issue.
Thank you very much!


Espouse some of the virtues of Cog in the readme

We should have whole sections for "Automatic Docker image", "No more CUDA hell", "Automatic HTTP service", etc, with code examples to really show off what Cog is doing and why it's cool.

Closed by #507.


[SPARK-36461][SQL] Enable ObjectHashAggregate for more Aggregate functions

What changes were proposed in this pull request?

Enabing more ObjectHashAggregate for more aggregate functions, as it has better performance compared to SortAggregate according to current benchmark.
Why are the changes needed?

We are pretty conservative with ObjectHashAggregate right now. Except for enabling it by configuring, there is also a fallback threshold. With the fallback threshold, it looks like that even ObjectHashAggregate is bad at memory estimation, it is unlikely to OOM easily. For now the users cannot work with ObjectHashAggregate for these aggregation functions even they enable the config. That's said, ObjectHashAggregate is not much able to be applicable under these limitations. As we are enough conservative with fallback threshold value, it is also disable-able using the config, the limitations on applicable aggregation functions look not necessary.
Does this PR introduce any user-facing change?

Yes. Some aggregations will be applied with ObjectHashAggregate after this change.
How was this patch tested?

Added unit tests.

Test build #140283 has started for PR 33068 at commit 672d07b.

Looked at ObjectHashAggregate , wondering why we don't enable some Aggregate functions on it. I ran it though existing tests, seems it is okay. Wanted to check with CI.

Kubernetes integration test unable to build dist.
exiting with code: 1
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/44814/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/44814/

Test build #140283 has finished for PR 33068 at commit 672d07b.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/140283/

A short discussion on this topic from a while back: https://github.com/apache/spark/pull/32057#issuecomment-818743773

Thanks for referring to previous discussion. I agree with @cloud-fan. However, currently it is not optional for users. I'm thinking if we can offer users options here?

Actually we already have spark.sql.execution.useObjectHashAggregateExec to control the use of ObjectHashAggregateExec. It sounds a bit redundant to add another config here.
I also think the current condition TypedImperativeAggregate is already more strict than others like ImperativeAggregate and DeclarativeAggregate.

cc @cloud-fan What do you think? I think we are conservative enough with the fallback threshold. With the fallback threshold, it looks like that even ObjectHashAggregateExec is bad at memory estimation, it is unlikely to OOM easily. For now the users cannot work with ObjectHashAggregateExec for these cases even they enable the config.

Test build #142242 has started for PR 33068 at commit 84a87f2.

Kubernetes integration test unable to build dist.
exiting with code: 1
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46749/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/46749/

Test build #142242 has finished for PR 33068 at commit 84a87f2.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/142242/

Test build #142245 has started for PR 33068 at commit 3dd644f.

Kubernetes integration test unable to build dist.
exiting with code: 1
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46752/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/46752/

Test build #142245 has finished for PR 33068 at commit 3dd644f.

This patch fails from timeout after a configured wait of 500m.
This patch merges cleanly.
This patch adds no public classes.

retest this please

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/142245/

Test build #142263 has started for PR 33068 at commit 3dd644f.

Test build #142263 has finished for PR 33068 at commit 3dd644f.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/142263/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46771/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46771/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/46771/

retest this please

Test build #142281 has started for PR 33068 at commit 3dd644f.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46789/

Kubernetes integration test status success
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/46789/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/46789/

Test build #142281 has finished for PR 33068 at commit 3dd644f.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/142281/


Support for custom type property mapping (Value Converters)

Prototype implementation:
https://github.com/Kentico/delivery-sdk-net/commit/f72373c252beadefc2eaf31e5bae3f60db6478e6
This would nicely solve scenarios such as:
https://forums.kenticocloud.com/discussion/49/support-nodatime-in-property-types#latest

fixed in #67


Image Importer Improvements

ref #4608, #4609, #4690

fix errors with cleaning up files
improve handling of base directories, and introduce a simple valid format for zips (must contain importable files or folders, and may contain up to one base directory)
vastly improve test coverage

Note: This PR comes before #4692, as it is a follow up to #4690 - will rebase the markdown one on this one.

As I was going through this I noticed a couple methods in importer/index.js that are returning promises when they don't need to (isValidZip and getBaseDirectory).  If they're switched to returning values/throwing errors it can make processZip and loadFile a little more straightforward and efficient.
I put up the changes here: https://github.com/jaswilli/Ghost/commit/ec6698fa720983fad7b25af5abe29096ac4f448b
Use or ignore :smile:.  I know you're trying to get to a destination that's further down the road than this PR--just playing around with this and thought I'd toss it out there.

Looks good to me - at one point I had branching code where the promises made more sense - but this is tonnes better now, just cherry picked your work into the PR :stuck_out_tongue_winking_eye:


Fix: token request can fail if password contains special characters

Hi thank you for creating this integration,
This Pull request updates the authentication request to URL encode the user credentials, solving the issue of special characters in the password causing login errors due to malformed HTTP request.
Issue:
Attempting to login with a password that contains special characters could result in "The user name or password is incorrect." error, even when the credentials are good.
After this fix:
The user's login was successful.

Thank you for the contribution


REQUEST: New membership for gdhuper

GitHub Username
@gdhuper
Requirements

[x] I have reviewed the community membership guidelines (https://github.com/dapr/community/blob/master/community-membership.md)
[x] I have enabled 2FA on my GitHub account. See https://github.com/settings/security
[x] I have subscribed to the Dapr community Gitter channel
[x] I am contributing (any of the following apply: issues, discussions, PRs, reviews) to 1 or more Dapr repositories

List of contributions to the Dapr project

PRs reviewed / authored
dapr/rust-sdk
dapr/rust-sdk
dapr/rust-sdk
dapr/rust-sdk
dapr/rust-sdk
dapr/cli
dapr/cli

Issues responded to
dapr/rust-sdk
dapr/cli
dapr/cli

Issue opened as requested by @youngbupark

I supported this request.

+1

Hey @gdhuper, look out for a GitHub invite in your mailbox.


Conflict

@spromicky
i have issue with addon conflict with another addon has the same commands ,
default Profile has chat on  /dc chat [on | off]
when i ever enter a dungeon i keep getting : you are not in a party , and the covanant chat not working .
The addon that has the same commands is : DynamicCam
can we do something about this ?

Hi, sure. You can use /dcovenants chat [on|off] instead.

becouse the other addon has the same cmd it wont print on the chat

character's covenant to chat
and keep give You are not in party in the chat

Can not check this, but you can disable DynamicCam addon, then turn off printing in chat for Details_Covenants. And after that enable DynamicCam.

i did that but problem still persists

if i turn DynamicCam off no massege apper

Conflict in commands make can't be a reason for this message. Only that one addon will respond for a command /dc that's all.
And if you disable DynamicCam and the message is gone maybe DynamicCam is the reason for the problem?

i report this issue on both addon , if you think this from DynamicCam i close ticket


Update readme with correct settings.json file path

Closed via https://github.com/iancleary/vm-ssh-config/commit/ab2a3696dad70a17e4f76a17f1d8f3c09dab7478


ci: build sway-libs

This is probably why the compatibility check might be failing. The test.toml has a dependency, hence the "failed to source dependency" error message here: https://github.com/FuelLabs/fuelup/actions/runs/4124188987/jobs/7126597387

Maybe we should setup a manual trigger for this workflow to allow for testing outside of the normal flow on master?

Maybe we should setup a manual trigger for this workflow to allow for testing outside of the normal flow on master?

If by testing you mean triggering the tests manually, the workflow is declared for workflow dispatch: https://github.com/FuelLabs/fuelup/actions/workflows/test-toolchain-compatibility.yml
You have to provide the input in a weird json format though, to tell the CI the combinations that the workflow has to test, for eg. the input for that failed run is: {"job":[{"forc-version":"0.35.0","fuel-core-version":"0.17.0"},{"forc-version":"0.35.0","fuel-core-version":"0.16.1"},{"forc-version":"0.33.1","fuel-core-version":"0.16.1"}]}


[Bug][Jira][REST API] Unable to set up Jira connection via API due to token length issue

Search before asking

[X] I had searched in the issues and found no similar issues.

What happened
I want to configure Jira Cloud connection settings using the REST API.
However, when executing the following command, I encounter an error indicating that the token length is too long:
curl -X 'POST'
'https://devlake.xxxxx/api/plugins/jira/connections'
-H 'accept: application/json'
-H 'Content-Type: application/json'
-d '{
"authMethod": "BasicAuth",
"endpoint": "https://xxxxx.atlassian.net/rest/",
"name": "jira-test-connection",
"password": "{jira-password}",
"proxy": "",
"rateLimitPerHour": 0,
"token": "{jira-token}",
"username": "{jira-username}"
}'
The error message received is:
{   "code": 0,   "success": false,   "message": "Error 1406 (22001): Data too long for column 'token' at row 1 (500)\nWraps: (2) Error 1406 (22001): Data too long for column 'token' at row 1\nError types: (1) *hintdetail.withDetail (2) *mysql.MySQLError",   "causes": null,   "data": null }
Jira personal access tokens are 192 characters long, but attempting to use a token of 169 characters or more results in this error.
Does Devlake support tokens of this length?
What do you expect to happen
I expect to be able to configure the Jira connection successfully by including the token in the request.
How to reproduce
After executing the command provided earlier to set up the Jira Cloud connection,
I attempted to test the connection using the following command:
curl -X 'POST'
'https://devlake.xxxxx/api/plugins/jira/connections/{connectionId}/test'
-H 'accept: application/json'
-H 'Content-Type: application/json'
Anything else
https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/
Following the documentation, using the token name as the username allows the request to go through, but results in a "Please check your credential (401)" error:
curl -X 'POST'
'https://devlake.xxxxx/api/plugins/jira/connections'
-H 'accept: application/json'
-H 'Content-Type: application/json'
-d '{
"authMethod": "BasicAuth",
"endpoint": "https://xxxxx.atlassian.net/rest/",
"name": "jira-test-connection",
"password": "{jira-password}",
"proxy": "",
"rateLimitPerHour": 0,
"token": "{jira-token}",
"username": "{jira-username}"
}'
-u '{jira-username}:{token-label}'
Jira's official documentation also assumes that applications will support token lengths:
https://community.atlassian.com/t5/Jira-Service-Management/How-to-generate-a-token-with-less-than-128-characters/qaq-p/2373530
Version
v.1.0.0-beta10
Are you willing to submit PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

@kamiyariko  Can you check token field in table _tool_jira_connections? It's length should be VARCHAT(255).

Yes, The type of the token field in the _tool_jira_connections table is varchar(255).

@kamiyariko  varchar(255) is enough for PAT with length 192, and I have tried to set an illegal token with length 193, it can be saved successfully.

Compared with your curl command, I think the root cause is token is in payload["password"] not payload["token"]. You can have a try.

That was a success! Thank you for your support.


undefined method `check' for #JPush::PushPayload:0x007fc79a19db88

from your example
payload =JPush::PushPayload.new(platform: JPush::Platform.all,
    audience: JPush::Audience.all,
    notification: JPush::Notification.new(alert: 'alert meassage')
).check

sorry it‘s old version’s examlpe，please see https://github.com/jpush/jpush-api-ruby-client/blob/master/example/push_example.rb


UDP timeout, retrying with TCP

Hello.
I have ffmpeg working correctly, but within my application I get this error: UDP timeout, retrying with TCP and I don't get the stream working.
Any solution for this?

Hello, did you solve this problem???
I have the same problem, UDP timeout, retrying with TCP and I don't get the stream working.
Help please, Help please, Help please!

Hi,
Use 0.0.7 version

But I suggest using version 0.0.3.

Hi,
Use 0.0.7 version

Couldn't get a stream with v0.0.3 or v0.0.7. I think the older versions are not compatible with the latest versions of JSMpeg.
Best solution for me was to install directly from the repo (not npm).
npm install --save https://github.com/kyriesent/node-rtsp-stream.git

@wizzfizz94
use ffmpeg
you can download it from https://ffmpeg.org/
good luck

But @ali-tafakkori i like this module :( ffmpeg doesn't create a streaming server unless you use it with ffserver which is a pain to configure and not node based.


RegistryConfig 注释似乎不全

https://github.com/apache/dubbo/blob/d98d48914b139d6abb2139ea36e51e536713edfe/dubbo-common/src/main/java/org/apache/dubbo/config/RegistryConfig.java#L76-L80
只列举了 1，没有列举其他

Thank you for your feedback, the community will continue to improve the code comments, and you are also welcome to participate in and improve together.


Problem Report not delivered until connection is active

See #2599 and PR #2600.
Problem Reports require an active connection for delivery. However, if the issue is in the early stages of the connection/didexchange protocols, we have no way of successfully communicating that back to the other agent. We do have logic that catches exceptions and fires a ProblemReport in the request and response handlers but those reports will be swallowed and not delivered because the underlying connection is not active.
SKIP_ACTIVE_CONN_CHECK_MSG_TYPES = [
    "didexchange/1.0/request",
    "didexchange/1.0/response",
    "connections/1.0/invitation",
    "connections/1.0/request",
    "connections/1.0/response",
]

....

        if (
            message.connection_id
            and msg_type
            and msg_type not in SKIP_ACTIVE_CONN_CHECK_MSG_TYPES
            and not await super().conn_rec_active_state_check(
                profile=context.profile,
                connection_id=message.connection_id,
            )
        ):
            raise RuntimeError(
                f"Connection {message.connection_id} is not ready"
                " which is required for sending outbound"
                f" message {msg_id} of type {msg_type}."
            )
        return await self._send(context.profile, message, self._inbound_message)

Should we add problem report the skip types? Which would allow the message to be delivered? or add some other flag/logic that would allow problem reports in the skipped type protocol stages to be delivered? Like a problem report that occurs during the execution of a skipped type?

Yes, we absolutely should be able to send the report but the current implementation prevents it. Because the message is of type notification/1.0/problem-report the current implementation will not deliver it until the connection has become active (for our purposes response state is "active" enough).
The errors that become problem reports are caught, turned into problem reports then the responder sends them, when they hit the dispatcher - that's where it checks the message type before it sends the DIDComm message. So we could add"notification/1.0/problem-report to the skip message types or use some other mechanism to allow those to be delivered.

Sorry, it's: didexchange/1.0/problem_report and connections/1.0/problem_report. Was doing a little investigation and it is more than just adding those to the SKIP_ACTIVE_CONN_CHECK_MSG_TYPES.  The actual handler (when receiving a problem report) needs to find the connection so it can set as abandoned. Need to figure out how to resolve given limited information in the message.  Looking into the resolution logic from other handlers.

Good progress on this, need to include #2598 with this; just makes sense to complete both connection and did problem report fixes.


Phaser.ScaleManager#fullScreenChange throws Uncaught TypeError

The fullScreenChange throws an Uncaught TypeError: Cannot read property 'dispatch' of undefined.
Had looked into the code(2.4.2) and this is still calling the deprecated enterFullScreen and leaveFullScreen.

you can follow the issue - https://github.com/photonstorm/phaser/issues/1971

This is fixed in dev.


Production Issue (require not defined)

Hi Elnur,I have submitted propasal for issue raised by you on upwork. Once approved ill submit my solution.

Did you write me on Upwork? If not, can you send me an email? And the image doesn't open<EMAIL_ADDRESS>

Yeah, please accept the proposal at Upwork


what is the relationship between xxx.semantic.txt and xxx.semantic.glb?

i get a rgb image from xxx.semantic.glb

and the floor RGB=(33, 185, 0)
but i cannot find a close color in xxx.semantic.txt about floor.
my code:

Hey @zuixiaosanlang
I believe your understanding is correct. The hex color in the text file should map to the color of the painted texture region in the .glb asset. We render a flat shaded image of that texture.
If you can provide the specific scene name here we can take a closer look.

Hi @zuixiaosanlang
The GLAQ4DNUx5U.semantic.txt semantic text file should contain 907 entries, but it seems the file you are reading in only has 23.
GLAQ4DNUx5U.semantic.txt

@jturner65
Hi,
0x87E719 should be rgb : 135, 231, 25.    0x19=1*16+9=25
use MeshLab tool to compare:

it seems the floor color in your picture  is more closer to rgb(33, 185, 0)

Hi  @aclegg3
00861-GLAQ4DNUx5U
also you can check other scene, for example 00006-HkseAnWCgqk. it is the same problem.
If it's my fault, please correct me.
thanks.

@jturner65 Hi, 0x87E719 should be rgb : 135, 231, 25. 0x19=1*16+9=25

Yes, that was a typo on my part, apologies, and thank you for correcting it.
Please let me know what mechanism you are using to query the color in your original post, so that as I attempt to figure out any potential issues I can follow the same pathway you did.
Thank you!

@jturner65
Hi,
i create tensor:

get rgb image from xxx.semantic.glb:

save rgb image:

then i check the floor color in rgb image, compared whith xxx.semantic.txt.

Are you setting up the sensor as a semantic sensor?

Hi, @jturner65
if i set sensor as a semantic sensor, i got all zeros.

then next line run failed
batch = batch_obs([observations])

@jturner65
i run the code and cannot get the semantic label.
https://aihabitat.org/docs/habitat-sim/image-extractor.html

and my env:

thanks.


feat: adds a new parameter to the logistic regression: solver

We need a new hyperparameter, solver for the logistic regression to support new solvers, see #70 and #63

lgtm,
@VolodymyrOrlov will you add in a future PR the changes to LogisticRegression in order to actually use this?

yes, I plan to work on SAGA solver: #70

lgtm,
@VolodymyrOrlov will you add in a future PR the changes to LogisticRegression in order to actually use this?

yes, I plan to work on SAGA solver: #70


http2-1.5.0

http2-1.5.0 depended on by:

[ ] warp-3.2.2 (==1.4.*). No maintainer. @snoyberg

Pinging @kazu-yamamoto

Current Warp requires http2 1.4.x.
The next version requires http2 1.5.x.
Any issues? I don't know what kind of issue is discussed here.

The issue is simply that http2 1.5 is released, while the next version of Warp is not, so Stackage can't start building with http2 1.5 until warp releases its corresponding upgrade.

Warp 3.2.3 has been released.

Thanks - hopefully it will be in tomorrow's nightly.

Reopening due to shimmercat/second-transfer#5 (and kazu-yamamoto/http2#7)

Please ignore last comment - let me disable second-transfer temporarily instead so we don't need to hold back warp too.


Feature: Migrate Commentator Partials to View Components

Is your feature request related to a problem? Please describe
Currently the Comment Section uses Partials for rendering Creating/Updating, Deleting, Showing, Voting UI.

[ ] _delete_comment_confirmation_modal.html.erb
[ ] _form.html.erb
[ ] _show.html.erb
[ ] _list.html.erb
[ ] _votes.html.erb
[ ] _body.html.erb

Describe the solution you'd like
We should migrate to View Component for better Performance and better testability.
Describe alternatives you've considered
No response
Additional context
No response
Are you working on this?
Yes

@tachyons can you please review this ?

@senbo1 are you still working on this issue?


A number of tests showing Failed or Started

Describe the bug
I have a number of tests showing Failed or Started interspersed with successful tests
To Reproduce
Unable to reproduce, seems to occur randomly
Expected behavior
No Failed or Started tests
Environment (please complete the following information):

OS: Docker on Synology
Architecture: amd64
Version: 0.18.3

Screenshots

Additional context
These started on March 13th but I only just noticed the issue, it looks like one of the servers I had defined is no longer active as it only shows the number in my server list with no name against it (it was 26075) but I'm not sure... I have deleted this server and will see if the issue reoccurs.

Same

It just says Server Selection - Failed to find a working test server. (NoServers)

It was working last month,

@rairulyle do you have a server list in your settings?

There is a server list in the settings, but 500 may appear irregularly. Refreshing will solve this problem

@lnlyssg do you have a list of servers or was it only one?

Also worth noting these are errors from the Speedtest CLI so its a good thing to see this as it's validating the server the app is passing to the CLI.

I have a list, to clarify what I posted originally one of the servers in my list was only showing the numbers and not the longer description. Since removing that server I haven't had any started or failed tests.

Hello it seems that i have the same issue....

the last speedtest seems to be at 8:39 on the admin pannel :

theses are the latest try :

and here is the latest try view results:

PS : Native french speaker sorry for the gammaticals errors

"solved" and speedtest on status completed from 9:48 till now it seems working i don't know where did that came from :

Its possible if you run too many tests you could be blocked but I haven't heard of it. Ookla speedtests are pretty data heavy coming in at ~1GB of data so just keep that in mind.


Feat / add slide boundary when using cycle mode stop

We have support for three "cycle modes" in the TileSlider library, but we didn't implement full support for the cycle mode stop yet, until now!
The issues found:

Swiping the slider causes an empty space
Sliding with the keys or API causes this as well
The velocity animation wasn't stopped when the boundary is reached

Here is how it works now:
https://github.com/user-attachments/assets/c599cb28-4bb0-4063-b64d-35538fe12b80
This PR addresses these issues and adds an example page with cycle mode set to stop. I refactored some of the drag clamping functions because these were repeated and both needed account for the cycle mode stop boundaries.

Great work @ChristiaanScheermeijer! And thanks for helping me out.
I noticed two issues, though. It will take me some time to point you to the root cause in the code, but hopefully you see it a lot quicker than me.
I can only reproduce these issues within my implementation and not on your demo-page. I can also reproduce it in "Responsive mode" of my desktop browser.

When you reached the end of a slider with MANY items, when you perform the last swipe it will go back to the beginning
When you reached the end of slider with 3 items, it will go one item back.

These issues doesn't occur at the start, only at the end.
You will see these issues in my screen recording. In my implementation I did nothing weird, so I suspect it being a bug in the calculation.
https://github.com/user-attachments/assets/51493d27-edb0-48e1-8e02-0f87d01eb515

I noticed two issues, though.

How about fixing this separately? This PR makes it a lot better, so then we can start using it. Today. :-)

Thanks @langemike, I think I also found this issue caused by 2 things;

I was using totalTiles which represents the tiles rendered including the overscan. This was, coincidentally, exactly the amount used in my tests...
The snap transition was a bit weird and I believe it is not needed. It can still be improved to visually see the edge snapping, but we can do this later!

I'm curious if you still see these issues when using the latest commit.

I'm curious if you still see these issues when using the latest commit.

This is PERFECT. It works really well, thanks for the fix!


retry_join_ec2 configuration settings missing

Hello,
Would it be possible to add the following configuration options to this role:
https://www.consul.io/docs/agent/options.html#retry_join_ec2
That way we can join a cluster more dynamically, based on ec2 tags.

acl_* config settings are also missing.
Will see if I have the time to come up with a PR soon :)